Network Working Group                                          J. Lennox
Request for Comments: 3880                                         X. Wu
Category: Standards Track                                 H. Schulzrinne
                                                     Columbia University
                                                            October 2004
                    Call Processing Language (CPL):
       A Language for User Control of Internet Telephony Services

Status of this Memo


This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.

この文書は、インターネットコミュニティのためのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD 1)の最新版を参照してください。このメモの配布は無制限です。

Copyright Notice


Copyright (C) The Internet Society (2004).




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.


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
       12.4.  Example: Call Screening . . . . . . . . . . . . . . . . 40
       12.5.  Example: Priority and Language Routing. . . . . . . . . 41
       12.6.  Example: Outgoing Call Screening. . . . . . . . . . . . 42
       12.7.  Example: Time-of-day Routing. . . . . . . . . . . . . . 43
       12.8.  Example: Location Filtering . . . . . . . . . . . . . . 44
       12.9.  Example: Non-signalling Operations. . . . . . . . . . . 45
       12.10. Example: Hypothetical Extensions. . . . . . . . . . . . 46
       12.11. Example: A Complex Example. . . . . . . . . . . . . . . 48
   13. Security Considerations. . . . . . . . . . . . . . . . . . . . 49
   14. IANA Considerations. . . . . . . . . . . . . . . . . . . . . . 49
       14.1.  URN Sub-Namespace Registration for
              urn:ietf:params:xml:ns:cpl. . . . . . . . . . . . . . . 49
       14.2.  Schema registration . . . . . . . . . . . . . . . . . . 50
       14.3.  MIME Registration . . . . . . . . . . . . . . . . . . . 50
   15. Acknowledgments. . . . . . . . . . . . . . . . . . . . . . . . 51
   A.  An Algorithm for Resolving Time Switches . . . . . . . . . . . 52
   B.  Suggested Usage of CPL with H.323. . . . . . . . . . . . . . . 53
       B.1.   Usage of "address-switch" with H.323. . . . . . . . . . 53
       B.2.   Usage of "string-switch" with H.323 . . . . . . . . . . 55
       B.3.   Usage of "language-switch" with H.323 . . . . . . . . . 55
       B.4.   Usage of "priority-switch" with H.323 . . . . . . . . . 55
       B.5.   Usage of "location" with H.323. . . . . . . . . . . . . 56
       B.6.   Usage of "lookup" with H.323. . . . . . . . . . . . . . 56
       B.7.   Usage of "remove-location" with H.323 . . . . . . . . . 56
   C.  The XML Schema for CPL . . . . . . . . . . . . . . . . . . . . 56
   Normative References . . . . . . . . . . . . . . . . . . . . . . . 70
   Informative References . . . . . . . . . . . . . . . . . . . . . . 71
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 73
   Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 74
1. Introduction
1. はじめに

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]及び323 [16]。

CPL is powerful enough to describe a large number of services and features, but it is limited in power so that it can run safely in Internet telephony servers. The intention is to make it impossible for users to do anything more complex (and dangerous) than describe Internet telephony services. The language is not Turing-complete, and provides no way to write loops or recursion.


CPL is also designed to be easily created and edited by graphical tools. It is based on the Extensible Markup Language (XML) [2], so parsing it is easy and many parsers for it are publicly available.


The structure of the language maps closely to its behavior, so an editor can understand any valid script, even ones written by hand. The language is also designed so that a server can easily confirm the validity of a script when the server receives it, rather than discovering problems while a call is being processed.


Implementations of CPL are expected to take place both in Internet telephony servers and in advanced clients; both can usefully process and direct users' calls. This document primarily addresses the usage in servers. A mechanism will be needed to transport scripts between clients and servers; this document does not describe such a mechanism, but related documents will.


The framework and requirements for the CPL architecture are described in RFC 2824, "Call Processing Language Framework and Requirements" [17].

CPLアーキテクチャのフレームワークと要件は、RFC 2824に記述されている、「コール処理言語フレームワークと要件」[17]。

1.1. Conventions of This Document
1.1. このドキュメントの表記規則

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.

この文書では、キーワード "MUST"、 "MUST NOT"、 "REQUIRED"、 "NOT SHALL"、 "推奨"、 "すべきではない" "べきである" "ないものと"、 "MAY"、および "オプション" 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.


2. Structure of CPL Scripts
2.1. High-level Structure
2.1. 高レベルの構造

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


A call processing action is a structured tree that describes the operations and decisions a telephony signalling server performs on a call set-up event. There are two types of call processing actions: top-level actions and subactions. Top-level actions are actions that are triggered by signalling events that arrive at the server. Two top-level actions are defined: "incoming", the action performed when a call arrives whose destination is the owner of the script, and "outgoing", the action performed when a call arrives whose originator is the owner of the script.

呼処理のアクションは、呼設定イベントで電話シグナリ​​ング・サーバが実行する操作と決定を説明する構造化された木です。トップレベルのアクションとサブアクション:コール処理アクションの2種類があります。トップレベルのアクションは、サーバーに到着シグナリングイベントによってトリガーされるアクションです。 2つのトップレベルのアクションが定義されています。コールは、その先のスクリプトの所有者である、と「出」、通話がその発信元のスクリプトの所有者である到着したときにアクションが実行到着したときに「入ってくる」、アクションが実行さ。

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.


2.2. Abstract Structure of a Call Processing Action
2.2. コール処理アクションの抽象構造

Abstractly, a call processing action is described by a collection of nodes that describe operations that can be performed or decisions that can be made. A node may have several parameters, which specify the precise behavior of the node; they usually also have outputs, which depend on the result of the decision or action.


For a graphical representation of a CPL action, see Figure 1. Nodes and outputs can be thought of informally as boxes and arrows; CPL is designed so that actions can be conveniently edited graphically using this representation. Nodes are arranged in a tree, starting at a single root node; outputs of nodes are connected to additional nodes. When an action is run, the action or decision described by the action's top-level node is performed; based on the result of that node, the server follows one of the node's outputs, and the subsequent node it points to is performed; this process continues until a node with no specified outputs is reached. Because the graph is acyclic, this will occur after a bounded and predictable number of nodes are visited.


If an output to a node does not point to another node, it indicates that the CPL server should perform a node- or protocol-specific action. Some nodes have specific default behavior associated with them; for others, the default behavior is implicit in the underlying signalling protocol, or can be configured by the administrator of the server. For further details on this, see Section 10.


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

Figure 1: Sample CPL Action: Graphical Version


2.3. Location Model
2.3. 所在地モデル

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


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


2.4. XML Structure
2.4. XML構造

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はタグの階層構造で構成されています。各タグには、多数の属性を持つことができます。両方の言語が以前より大きな標準のSGML [19]の単純化されているように、それは、視覚的及び構造的にHTML [18]と非常に類似しています。

See Figure 2 for the XML document corresponding to the graphical representation of the CPL script in Figure 1. Both nodes and outputs in CPL are represented by XML tags; parameters are represented by XML tag attributes. Typically, node tags contain output tags, and vice-versa (with a few exceptions: see Sections 5.1, 5.3, 7.1, and 7.2).


The connection between the output of a node and another node is represented by enclosing the tag representing the pointed-to node inside the tag for the outer node's output. Convergence (several outputs pointing to a single node) is represented by subactions, discussed further in Section 8.


The higher-level structure of a CPL script is represented by tags corresponding to each piece of ancillary information, subactions, and top-level actions, in order. This higher-level information is all enclosed in a special tag "cpl", the outermost tag of the XML document.


A complete XML Schema for CPL is provided in Appendix C. The remainder of the main sections of this document describe the semantics of CPL, while giving its syntax informally. For the formal syntax, please see the appendix.


3. Script Structure: Overview

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

上述したように、CPLスクリプトが付属情報、サブアクション、およびトップレベルのアクションから成ります。 「CPL」ノードの完全な構文は、図3に示されています。

<?xml version="1.0" encoding="UTF-8"?> <cpl xmlns="urn:ietf:params:xml:ns:cpl" xmlns:xsi="" xsi:schemaLocation="urn:ietf:params:xml:ns:cpl cpl.xsd "> <subaction id="voicemail"> <location url=""> <redirect /> </location> </subaction> <incoming> <address-switch field="origin" subfield="host"> <address subdomain-of=""> <location url=""> <proxy timeout="10"> <busy> <sub ref="voicemail" /> </busy> <noanswer> <sub ref="voicemail" /> </noanswer> <failure> <sub ref="voicemail" /> </failure> </proxy> </location>

<?xml version = "1.0" エンコード= "UTF-8"?> <CPLののxmlns = "壷:IETF:のparams:XML:NS:CPL" のxmlns:XSI = " / XMLスキーマ・インスタンス」のxsi:のschemaLocation = "URN:IETF:paramsは:XML:NS:> ":CPLは "> <サブアクションID =" ボイスメール"> <場所のURL =" SIPをcpl.xsd <リダイレクト/> </場所> </サブアクション> <着信> <アドレス・スイッチ・フィールド= "オリジン" サブフィールド= "ホスト"> <場所のURL = "SIP < ""=サブドメイン-のアドレス>:ジョーンズ@ "> <プロキシタイムアウト=" 10 "> <忙しい> <サブREF =" ボイスメール」/> </忙しい> <noanswer> <サブREF = "ボイスメール" /> </ noanswer> <失敗> <サブREF = "ボイスメール" /> </失敗> </プロキシ> </場所>

</address> <otherwise> <sub ref="voicemail" /> </otherwise> </address-switch> </incoming> </cpl>

</アドレス> <そうでない> <サブREF = "ボイスメール" /> </さもなければ> </アドレススイッチ> </着信> </ CPL>

Figure 2: Sample CPL Script: XML Version


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


Figure 3: Syntax of the top-level "cpl" tag


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

トップレベルのアクションとサブアクションの両方、処理アクションを呼び出して、ノードと出力のツリーから成ります。ノードと出力は両方のXMLタグによって記述されています。 CPLノードの4種類がある:スイッチ、CPLスクリプトを作ることができる選択肢を表し、追加または操作をシグナリング、位置セットから位置を削除する位置調整剤、シグナリングプロトコルでイベント、および非シグナリングオペレーションを引き起こし、これは基本的なプロトコルに影響を与えていない行動を誘発します。

4. Switches

Switches represent choices a CPL script can make, based on either attributes of the original call request or items independent of the call.


All switches are arranged as a list of conditions that can match a variable. Each condition corresponds to a node output; the output points to the next node that should be executed if the condition is true. The conditions are tried in the order they are presented in the script; the output corresponding to the first node to match is taken.


There are two special switch outputs that apply to every switch type. The output "not-present", which MAY occur anywhere in the list of outputs, is true if the variable the switch was to match was not present in the original call setup request. (In this document, this is sometimes described by saying that the information is "absent".)

すべてのスイッチタイプに適用されます二つの特別なスイッチの出力があります。スイッチが一致した変数は、元の呼設定要求には存在しなかった場合はどこにも出力のリストで起こるかもしれない「 - 存在しない」出力は、真です。 (この文書では、これは、時には情報が「無し」であることを言って記載されています。)

The output "otherwise", which MUST be the last output specified if it is present, matches if no other condition matched.


If no condition matches and no "otherwise" output was present in the script, the default script behavior is taken. See Section 10 for more information on this.


Switches MAY contain no outputs. They MAY only contain an "otherwise" output.


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


4.1. Address Switches
4.1. アドレススイッチ

Address switches allow a CPL script to make decisions based on one of the addresses present in the original call request. They are summarized in Figure 4.


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

ノード:「アドレススイッチ」を出力:「アドレス」パラメータと一致する特定のアドレス:「フィールド」「原点」、「宛先」、または「オリジナル先」「サブフィールド」「アドレス型」、「ユーザ」、「ホスト」、 『ポート』、 『TEL』、または 『表示』(も: 『パスワード』と 『エイリアス型』)

Output: "address" Parameters: "is" Exact match "contains" Substring match (for "display" only) "subdomain-of" Sub-domain match (for "host", "tel")


Figure 4: Syntax of the "address-switch" node


Address switches have two node parameters: "field" and "subfield". The mandatory "field" parameter allows the script to specify which address is to be considered for the switch: either the call's origin address (field "origin"), its current destination address (field "destination"), or its original destination (field "original-destination"), the destination the call had before any earlier forwarding was invoked. Servers MAY define additional field values.


The optional "subfield" specifies which part of the address is to be considered. The possible subfield values are: "address-type", "user", "host", "port", "tel", and "display". Additional subfield values MAY be defined for protocol-specific values. (The subfield "password" is defined for SIP in Section 4.1.1; the subfield "alias-type" is defined for H.323 in Appendix B.1.) If no subfield is

オプションの「サブフィールド」を指定したアドレスの一部を考慮する必要があります。可能なサブフィールド値は「アドレス型」、「ユーザ」、「ホスト」、「ポート」、「TEL」、および「表示」。追加のサブフィールドの値は、プロトコル固有の値に対して定義されてもよいです。 (サブフィールド「パスワード」は、セクション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.


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]テキスト表現形式で、インターネットホスト名またはアドレスに対応するIPアドレスを示します。ホスト名は文字列として比較されます。 IPアドレスは数値的に比較されます。 (特に、IPv6の::省略ゼロビットブロックの存在または位置が目的に合致するために重要ではない。)ホスト名をIPアドレスに等しいことはありません - ないDNS解決を行いません。 IPv4アドレスは、IPv6アドレスがV4-で-v6の埋め込みであっても、IPv6アドレスに等しいことはありません。このサブフィールドは、大文字と小文字が区別されず、存在しなくてもよいです。

            For host names only, subdomain matching is supported with
            the "subdomain-of" match operator.  The "subdomain-of"
            operator ignores leading dots in the hostname or match
            pattern, if any.

port: This subfield indicates the TCP or UDP port number of the address, numerically, in decimal format. It is not case sensitive, as it MUST only contain decimal digits. Leading zeros are ignored.


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


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で説明大文字と小文字を区別しないアルゴリズムを使用して整合されます。 「を含む」演算子は、それに適用することができます。これは、存在しなくてもよいです。

For any completely unknown subfield, the server MAY reject the script at the time it is submitted with an indication of the problem; if a script with an unknown subfield is executed, the server MUST consider the "not-present" output to be the valid one.


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


is: An output with this match operator is followed if the subfield being matched in the "address-switch" exactly matches the argument of the operator. It may be used for any subfield, or for the entire address if no subfield was specified.


subdomain-of: This match operator applies only for the subfields "host" and "tel". In the former case, it matches if the hostname being matched is a subdomain of the domain given in the argument of the match operator; thus, subdomain-of="" would match the hostnames "", "", and "". 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."

サブドメイン-の:このマッチ演算子は、サブフィールド「ホスト」と「TEL」に適用されます。一致しているホスト名が一致演算の引数で指定されたドメインのサブドメインである場合、前者の場合には、一致します。従って、 "" =-のサブドメインがホスト名と一致するであろう ""、 ""、および ""。 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.


4.1.1. Usage of "address-switch" with SIP
4.1.1. SIPと「アドレス・スイッチ」の使い方

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


The "display" subfield of an address is the display-name part of the address, if it is present. Because of SIP's syntax, the "destination" address field will never have a "display" subfield.


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


For SIP URIs, the "user", "host", and "port" subfields correspond to the "user," "host," and "port" elements of the URI syntax. (Note that, following the definitions of RFC 3261 [1], a SIP URI which does not specify a port is not the same as an explicit port 5060; the former is indicated by an absent port subfield.) The "tel" subfield is defined to be the "user" part of the URI, with visual separators stripped, if the "user=phone" parameter is given to the URI, or if the server is otherwise configured to recognize the user part as a telephone number. An additional subfield, "password", is defined to correspond to the "password" element of the SIP URI, and is case-sensitive. However, use of this field is NOT RECOMMENDED for general security reasons.

SIP URIのために、「ユーザ」、「宿主」、および「ポート」サブフィールドは、「ユーザ」、「宿主」、および「URIシンタックスのポート」要素に対応します。 (RFC 3261の定義は以下の[1]、SIP URIポートを指定しない、ということに注意することは、明示的なポート5060と同じではない;前者は存在しないポートのサブフィールドで示されている)、「TEL」サブフィールドであります「ユーザ= phone」パラメータがURIに指定された場合、またはサーバが他の電話番号等のユーザ部分を認識するように構成されている場合、視覚セパレータを剥離して、URIの「ユーザ」部分であると定義されます。追加のサブフィールド、「パスワード」は、SIP URIの「パスワード」要素に対応するように定義され、大文字と小文字が区別されています。しかし、このフィールドの使用は、一般的なセキュリティ上の理由から推奨されません。

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.

TELのURLについては、「TEL」と「ユーザー」のサブフィールドは、加入者名です。前者の場合には、視覚的なセパレータは削除されます。 「ホスト」と「ポート」サブフィールドは両方存在しません。

For h323 URLs, subfields MAY be set according to the scheme described in Appendix B.


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


If no subfield is specified for addresses in SIP messages, the string matched is the URI part of the address. For "is" matches, standard SIP URI matching rules are used; for "contains" matches, the URI is used verbatim.

何のサブフィールドは、SIPメッセージ内のアドレス指定されていない場合、マッチした文字列は、アドレスのURIの一部です。一致は、標準のSIP URIマッチング規則が使用されている「です」。 「を含む」一致のために、URIがそのまま使用されます。

4.2. String Switches
4.2. 文字列のスイッチ

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


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

Output: "string" Parameters: "is" Exact match "contains" Substring match


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


String switches have one node parameter: "field". The mandatory "field" parameter specifies which string is to be matched.


String switches are dependent on the call signalling protocol being used.


Four fields are defined and listed below. The value of each of these fields is a free-form Unicode string with no other structure defined.


subject: The subject of the call.


organization: The organization of the originator of the call.


user-agent: The name of the program or device with which the call request was made.


display: Free-form text associated with the call, intended to be displayed to the recipient, with no other semantics defined by the signalling protocol.


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

文字列は次のようにして、大文字と小文字を区別しないUnicode文字列として一致しています。 [5] Unicode規格付属書#15で指定されるように、まず、文字列は、「互換性組成物」(KC)を形成するために正規化されます。次に、文字列は#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の標準クラスライブラリで大文字と小文字を区別しない文字列比較は、既に第2工程を行います。他の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.


4.2.1. Usage of "string-switch" with SIP
4.2.1. SIPと「文字列スイッチ」の使い方

For SIP, the fields "subject", "organization", and "user-agent" correspond to the SIP header fields with the same name. These are used verbatim as they appear in the message.


The field "display" is not used, and is never present.


4.3. Language Switches
4.3. 言語の切り替え

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


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


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


Figure 6: Syntax of the "language-switch" node


Language switches take no parameters.


The "language" output takes one parameter, "matches". The value of the parameter is a language-tag, as defined in RFC 3066 [7]. The caller may have specified a set of language-ranges, also as defined in RFC 3066. The CPL server checks each language-tag specified by the script against the language-ranges specified in the request.

「言語」の出力は、「マッチ」は、1つのパラメータを取ります。 [7] RFC 3066で定義されているパラメータの値は、言語タグです。 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.

呼び出し側が特別な言語範囲「*」を指定した場合、それはマッチングの目的のために無視されます。 0の「Q」の値を持つ言語も無視されます。

This switch MAY be not-present.


4.3.1. Usage of "language-switch" with SIP
4.3.1. SIPと「言語切り替え」の使い方

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


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


4.4. Time Switches
4.4. タイムスイッチ

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


Time switches are independent of the underlying signalling protocol.


Node: "time-switch" Outputs: "time" Specific time to match Parameters: "tzid" RFC 2445 Time Zone Identifier "tzurl" RFC 2445 Time Zone URL

ノード:「タイムスイッチ」出力:パラメータと一致するように、「時間」、特定の時間:「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 DATE-TIME)の間隔(RFC 2445 DATE-TIME) "期間" 間隔の長さ(RFC 2445 DURATION)の "DTEND" 終了 "FREQ" 周波数再発の(「第二」、「細かく」、「時間給」、「毎日」、「毎週」「毎月」、または「毎年」)再発のバウンド「まで」「間隔」どのくらいの頻度で再発を繰り返す(RFC 2445 DATE-TIME )「カウント」再発の発生数「BYSECOND」分の分「BYMINUTE」リスト内の秒の一覧時間以内、一日の時間の「BYHOUR」リストの週の「BYMONTHDAY」リストの日のリスト「BYDAY」年「のWkst」の数ヶ月のリスト「BYMONTH」年の週のリスト「BYWEEKNO」年の日の月の日「byyearday」リストイベントのセット内の値の作業週「BYSETPOS」リストの最初の日指定されました

Figure 7: Syntax of the "time-switch" node


Time switches are based closely on the specification of recurring intervals of time in the Internet Calendaring and Scheduling Core Object Specification (iCalendar COS), RFC 2445 [8].

タイムスイッチはRFC 2445、インターネットカレンダーおよびスケジューリング中核オブジェクト仕様(iCalendarのCOS)における時間の繰り返し間隔の仕様に密接に基づいている[8]。

This allows CPL scripts to be generated automatically from calendar books. It also allows us to re-use the extensive existing work specifying time intervals.


If future standards-track documents are published that update or obsolete RFC 2445, any changes or clarifications those documents make to recurrence handling apply to CPL time-switches as well.

将来の標準トラック文書がその更新または廃止されたRFC 2445を公開している場合は、すべての変更または明確化は、それらの文書は、同様にCPLタイムスイッチに適用取り扱い再発することにします。

An algorithm to determine whether an instant falls within a given recurrence is given in Appendix A.


The "time-switch" tag takes two optional parameters, "tzid" and "tzurl", both of which are defined in RFC 2445 (Sections and 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.

「タイムスイッチ」タグは、RFC 2445(それぞれ、セクション4.8.3.1および4.8.3.5)で定義され、どちらも2つのオプションのパラメータ、「TZID」及び「tzurl」をとります。 「TZIDは、」タイムゾーン定義が参照される識別ラベルです。それはスラッシュ(斜線)で始まる場合、それはTO-定義するグローバルタイムゾーンのレジストリを参照します。それ以外の場合は、サーバーでローカルに定義されています。 「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」ラベルがローカルに定義されているが、サーバが少なくともオルソンタイムゾーンデータベース[9]で使用される命名規則をサポートすることが推奨されます。オルソン方式を用いるタイムゾーンデータベースの例は、ほとんどのUnixライクなシステムにzoneinfoのファイル、および標準のJava TimeZoneのクラスです。

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時までの間で開催されたtime-of-dayルーティングルールは、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.


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

タイム・ノードは、それらの出力が取られるべきれる期間のリストを指定します。リストの最初の期間の開始を指定し、「DTSTART」、および「DTEND」または「期間」の正確に一つの、それぞれ、終了時刻または期間の長さを指定します。彼らは、2つの必須パラメータがあります。 RFC 2445のセクション4.3.5で指定されるように "DTSTART" と "DTEND" パラメータは、のiCalendar COS DATE-TIME値としてフォーマットされている[8]。タイムゾーンがトップレベル「時間スイッチ」タグで指定されているので、わずか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」パラメータを含むことによって特定されます。 「DTSTART」、「DTEND」、および「期間」以外のパラメータは、CPLサーバが存在し、このようなパラメータを使用してスクリプトを受け入れ、および他のパラメータを無視すべきであるにもかかわらず、「FREQ」は、存在しない限り、指定しないでください。

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」パラメータは、次のいずれかの値をとり、「第二」、毎時」、分以上の間隔に基づいて、繰り返し期間を指定するために、秒以上、「微細」の間隔に基づいて、繰り返し期間を指定します」、繰り返し時間の間隔に基づいて期間以上を指定するには、 『週の間隔に基づいて、繰り返し期間を指定するには、『毎週』、一日以上の間隔に基づいて、繰り返し期間を指定するには、』毎日または年以上の間隔に基づいて、繰り返し期間を指定するには、月以上の間隔に基づいて、繰り返し期間を指定し、「毎年」ことが、より、「毎月」。これらの値は、大文字と小文字は区別されません。

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.

「間隔」パラメータは繰り返しルールが繰り返される頻度を表す正の整数が含まれています。デフォルト値は「第二に、」ルールの毎秒を意味し、「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 specified in UTC time format. If not present, and the "count" parameter is not also present, the recurrence is considered to repeat forever.

パラメータは、包括的な方法で繰り返しルールの境界のiCalendar COS日付または日時値を定義する「まで」。で指定された値が「まで」指定の再発と同期している場合は、この日付または日付時刻は、再発の最後のインスタンスになります。日付時刻値として指定した場合、それはUTC時刻形式で指定する必要があります。現在、そして「カウント」パラメータではありませんが、また、存在しない場合、再発は永遠に繰り返すように考えられています。

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.

「カウント」パラメータは再発を結合する範囲れる出現数を定義します。 「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.


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」は、「FR」は金曜日を示し、水曜日、「TH」は木曜日を示す示し、「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 -1〜31、または-31です。例えば、-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).


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 -1〜53、または-53です。これは、ISO 8601 [20]で定義されるように週番号付けによる週に相当します。週(「のWkst」を参照)週間のスタートとなるように定義週の日に開始し、7日間の期間として定義されます。暦年の週番号1は、その暦年中に少なくとも4日を含む最初の週です。このパラメータは、「毎年」のルールに対してのみ有効です。たとえば、3年の第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.


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


The "wkst" parameter specifies the day on which the work week starts. Valid values are "MO", "TU", "WE", "TH", "FR", "SA" and "SU". This is significant when a "weekly" recurrence has an interval greater than 1, and a "byday" parameter is specified. This is also significant in a "yearly" recurrence when a "byweekno" parameter is specified. The default value is "MO", following ISO 8601 [20].

「の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:


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

<時間-timerange- FREQ = "毎月" 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パラメータ値が使用可能スコープ(月に、すなわち、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は=「毎日」BYMONTH =「1」月にすべての日に(「BYMONTH」パラメータが存在しない場合)すべての日から再発インスタンスの数を減少させます。周波数未満の時間の間Byxxxパラメータは、一般的再発の発生数を増加または拡張。 2(「BYMONTH」パラメータが存在しない場合)は、例えば、FREQ =「毎年」BYMONTH =「1,2」1からセット毎年再発日以内の数を増加させます。

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パラメータが指定されている場合、指定された「FREQ」及び「間隔」パラメータを評価した後、Byxxxパラメータは、次の順序で評価オカレンスの現在のセットに適用される:「BYMONTH」、「BYWEEKNO」、「byyearday」、 "BYMONTHDAY"、 "BYDAY"、 "BYHOUR"、 "BYMINUTE"、 "BYSECOND"、および "BYSETPOS"。その後、評価され、「まで」「カウント」と。

Here is an example of evaluating multiple Byxxx parameters.


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

<時間DTSTART = "19970105T083000" 期間= "10M" FREQ = "毎年" 間隔= "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.

まず、間隔=「2」が到着する=「毎年」FREQするために適用される「隔年。」その後、BYMONTH =「1」が到着して適用される「毎年1月、隔年。」その後、BYDAY =「SU」は到着に適用される「1月中毎週日曜日、隔年。」その後、BYHOUR =「8,9」に到着するために適用されるだろう「8 AMと9 AM、隔年で1月には毎週日曜日。」その後、BYMINUTE =「30」に到達するように適用される「8:30 9:30 AM、隔年で1月中毎週日曜日。」続いて第二は、八時40分00秒AMに午前8時30分00秒AMから1月に毎週日曜日」で終わるために「DTSTART」から派生してからと九時40分00秒AMに9時30分00秒AMれ、 1年おきに。"同様に、欠落していた「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再発ルールは、具体的に時間スイッチノードのコンポーネントにマップされていません。例外ルールと同等の機能は、以前のルールを使用して時間を除外するためにスイッチルールの順序付けを使用することによって達成することができます。付加日付RDATE規則と同等の機能が同じ後続のノードに複数の出力をリンクする「サブ」ノード(セクション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.


4.4.1. iCalendar Differences and Implementation Issues
4.4.1. iCalendar形式の違いと実装の問題

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

このセクションのイベント繰り返しの仕様は、唯一の追加の制限を有する、[8] RFC 2445と(構文およびフォーマットの問題を除いて)同一です。そのつの制限は、繰り返し間隔の連続したインスタンスが重複しないことです。

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.

これは、全体のiCalendar COS再発仕様はCPLに含まれるべきかどうか、CPLの設計の際に、いくつかの議論の問題だった、またはサブセットのみが含まれるべきかどうか。それは、最終的に2つのプロトコル間の互換性が最も重要であったことを決定しました。これは、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再発によって定義された間隔の1つに入るかどうかを、一定の時間で、決定することが可能であるようには見えません。次のように主な関心事は、以下のとおりです。

o The "count" parameter cannot be checked in constant running time, since it requires that the server enumerate all recurrences from "dtstart" to the present time, in order to determine whether the current recurrence satisfies the parameter. However, a server can expand a "count" parameter once, off-line, to determine the date of the last recurrence. This date can then be treated as a virtual "until" parameter for the server's internal processing.


o Similarly, the "bysetpos" parameter requires that the server enumerate all instances of the occurrence from the start of the current recurrence set until the present time. This requires somewhat more complex pre-processing, but generally, a single recurrence with a "bysetpos" parameter can be split up into several recurrences without them.


o Finally, constant running time of time switches also requires that a candidate starting time for a recurrence can be established quickly and uniquely, to check whether it satisfies the other restrictions. This requires that a recurrence's duration not be longer than its repetition interval, so that a given instant cannot fall within several consecutive potential repetitions of the recurrence. The restriction that consecutive intervals not overlap partially satisfies this condition, but does not fully ensure it. Again, to some extent pre-processing can help resolve this.


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


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


4.5. Priority Switches
4.5. 優先スイッチ

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.


             Node:  "priority-switch"
          Outputs:  "priority"         Specific priority to match
       Parameters:  None

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


Figure 8: Syntax of the "priority-switch" node


Priority switches take no parameters.


The "priority" tag takes one of the three parameters "greater", "less", or "equal". The values of these parameters are one of the following priorities: in decreasing order, "emergency", "urgent", "normal", and "non-urgent". These values are matched in a case-insensitive manner. Outputs with the "less" parameter are taken if the priority of the call is less than the priority given in the argument, and so forth.

「優先度」タグは、次の3つのパラメータ、「大きい」、「以下」、または「等しい」のいずれかをとります。高い順に、「緊急」、「緊急」、「ノーマル」、および「非緊急」:これらのパラメータの値は、次の優先事項の一つです。これらの値は、大文字と小文字を区別しないように一致しています。 「少ない」パラメータと出力は等々、コールの優先順位は、引数に与えられた優先度よりも小さい場合に取る、とされています。

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


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


4.5.1. Usage of "priority-switch" with SIP
4.5.1. SIPと「優先スイッチ」の使い方

The priority of a SIP message corresponds to the "Priority" header in the initial "INVITE" message.


5. Location Modifiers

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

CPLの抽象場所モデルは、2.3節に記述されています。 (第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.


5.1. Explicit Location
5.1. 明示的な場所

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


Explicit location nodes are dependent on the underlying signalling protocol.


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


Figure 9: Syntax of the "location" node


Explicit location nodes have three node parameters. The mandatory "url" parameter's value is the URL of the address to add to the location set. Only one address may be specified per location node; multiple locations may be specified by cascading these nodes.


The optional "priority" parameter specifies a priority for the location. Its value is a floating-point number between 0.0 and 1.0. If it is not specified, the server SHOULD assume a default priority of 1.0. The optional "clear" parameter specifies whether the location set should be cleared before adding the new location to it. Its value can be "yes" or "no", with "no" as the default.


Basic location nodes have only one possible result, since there is no way that they can fail. (If a basic location node specifies a location which isn't supported by the underlying signalling protocol, the script server SHOULD detect this and report it to the user at the time the script is submitted.) Therefore, their XML representations do not have explicit output tags; the <location> tag directly contains another node.

彼らは失敗することができます方法はありませんので、基本的な場所ノードは、唯一の可能な結果を​​持っています。 (基本的な位置ノードは、基礎となるシグナリングプロトコルによってサポートされていない場所を指定している場合、スクリプトサーバは、これを検出し、スクリプトが提出された時点でユーザーにそれを報告しなければならない。)ので、そのXML表現が明示的にありません出力タグ。 <場所>タグは、直接別のノードを含みます。

5.1.1. Usage of "location" with SIP
5.1.1. SIPと「場所」の使い方

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


5.2. Location Lookup
5.2. 場所検索

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


Location lookup is dependent on the underlying signalling protocol.


Node: "lookup" Outputs: "success" Next node if lookup was successful "notfound" Next node if lookup found no addresses "failure" Next node if lookup failed Parameters: "source" Source of the lookup "timeout" Time to try before giving up on the lookup "clear" Whether to clear the location set before adding the new values


Output: "success" Parameters: none


Output: "notfound" Parameters: none


Output: "failure" Parameters: none


Figure 10: Syntax of the "lookup" node


Location lookup nodes have one mandatory parameter and two optional parameters. The mandatory parameter is "source", the source of the lookup. This can either be a URI, or a non-URI value. If the value of "source" is a URI, it indicates a location which the CPL server can query to obtain an object with the text/uri-list media type (see the IANA registration of this type, which also appears in RFC 2483 [10]). The query is performed verbatim, with no additional information (such as URI parameters) added. The server adds the locations contained in this object to the location set.

場所検索ノードは1つの必須パラメーターと2つのオプションのパラメータがあります。必須パラメータは、「ソース」、検索の源です。これは、URI、または非URI値のいずれかとすることができます。 「ソース」の値がURIであるならば、それは([また、RFC 2483に表示される、このタイプのIANA登録を参照してくださいCPLサーバーは、uriテキスト/リストメディアタイプを持つオブジェクトを取得するために照会することができる場所を示します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.


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.


Non-URL sources indicate a source not specified by a URL which the server can query for addresses to add to the location set. The only non-URL source currently defined is "registration", which specifies all the locations currently registered with the server.


The "lookup" node also has two optional parameters. The "timeout" parameter specifies the time, as a positive integer number of seconds, the script is willing to wait for the lookup to be performed. If this is not specified, its default value is 30. The "clear" parameter specifies whether the location set should be cleared before the new locations are added.

「参照」ノードは、2つのオプションのパラメータがあります。 「タイムアウト」パラメータは秒の正の整数として、スクリプトは検索が実行されるのを待つために喜んで、時間を指定します。これが指定されていない場合、デフォルト値は「クリア」パラメータは新しい場所が追加される前に、ロケーションセットをクリアする必要があるかどうかを指定する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」、および「失敗」:検索は、3つの出力があります。 NOTFOUNDは、ルックアップ・プロセスが成功した場合にとられるが、任意の場所を見つけることができませんでした。検索は、指定されたタイムアウトを超過したことを含め、何らかの理由で失敗した場合に障害がとられています。与えられた出力が存在しない場合、スクリプトの実行が終了し、デフォルトの動作が行われます。

5.2.1. Usage of "lookup" with SIP
5.2.1. SIPでの「検索」の使い方

For SIP, the "registration" lookup source corresponds to the locations registered with the server using "REGISTER" messages.


5.3. Location Removal
5.3. 場所の削除

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


The meaning of this node is dependent on the underlying signalling Protocol.


             Node:  "remove-location"
          Outputs:  None               (Next node follows directly)
        Next node:  Any node
       Parameters:  "location"         Location to remove

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


A "remove-location" node removes locations from the location set. It is primarily useful following a "lookup" node. An example of this is given in Section 12.8.


The "remove-location" node has one optional parameter. The parameter "location" gives the URI of a location to be removed from the set, in a signalling-protocol-dependent manner. If this parameter is not given, all locations are removed from the set.


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は、「削除-場所」タグは、直接次のノードのタグを囲みます。

5.3.1. Usage of "remove-location" with SIP
5.3.1. SIPと「削除-場所」の使用

The location specified in the "location" parameter of the "remove-location" node is matched against the location set using the standard rules for SIP URI matching (as are used, e.g., to match Contact addresses when refreshing registrations).

「削除ロケーションを」ノードの「位置」パラメータで指定された場所は、(使用されているように、リフレッシュ登録、例えば、連絡先アドレスと一致する)SIP URIマッチングのための標準的な規則を使用して位置セットと照合されます。

6. Signalling Operations

Signalling operation nodes cause signalling events in the underlying signalling protocol. Three signalling operations are defined: "proxy," "redirect," and "reject."


6.1. Proxy
6.1. 代理

Proxy causes the triggering call to be forwarded on to the currently specified set of locations. The syntax of the proxy node is given in Figure 12.


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


Node: "proxy" Outputs: "busy" Next node if call attempt returned "busy" "noanswer" Next node if call attempt was not answered before timeout "redirection" Next node if call attempt was redirected "failure" Next node if call attempt failed "default" Default next node for unspecified outputs Parameters: "timeout" Time to try before giving up on the call attempt "recurse" Whether to recursively look up redirections "ordering" What order to try the location set in.


Output: "busy" Parameters: none


Output: "noanswer" Parameters: none


Output: "redirection" Parameters: none


Output: "failure" Parameters: none


Output: "default" Parameters: none


Figure 12: Syntax of the "proxy" node


After a proxy operation has completed, the CPL server chooses the "best" response to the call attempt, as defined by the signalling protocol or the server's administrative configuration rules.


If the call attempt was successful, CPL execution terminates and the server proceeds to its default behavior (normally, to allow the call to be set up). Otherwise, the next node corresponding to one of the "proxy" node's outputs is taken. The "busy" output is followed if the call was busy, "noanswer" is followed if the call was not answered before the "timeout" parameter expired, "redirection" is followed if the call was redirected, and "failure" is followed if the call setup failed for any other reason.


If one of the conditions above is true, but the corresponding output was not specified, the "default" output of the "proxy" node is followed instead. If there is also no "default" node specified, CPL execution terminates and the server returns to its default behavior (normally, to forward the best response upstream to the originator).


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


If no locations were present in the set, or if the only locations in the set were locations to which the server cannot proxy a call (for example, "http" URLs), the "failure" output is taken.


Proxy has three optional parameters. The "timeout" parameter specifies the time, as a positive integer number of seconds, to wait for the call to be completed or rejected; after this time has elapsed, the call attempt is terminated and the "noanswer" branch is taken. If this parameter is not specified, the default value is 20 seconds if the "proxy" node has a "noanswer" or "default" output specified; otherwise the server SHOULD allow the call to ring for a reasonably long period of time (to the maximum extent that server policy allows).

プロキシは、3つのオプションパラメータがあります。 「タイムアウト」パラメータは、コールが完了または拒否されるのを待つために、秒の正の整数として、時間を指定します。この時間が経過した後、コール試行が終了し、「noanswer」ブランチがとられています。このパラメータが指定されていない場合は「プロキシ」ノードが「noanswer」または指定された「デフォルト」の出力を持っている場合、デフォルト値は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".

2番目のオプションのパラメータは2つの値を取ることができ、「再帰」、である、「はい」または「いいえ」。これは、サーバーが自動的に初期サーバから返されたリダイレクト応答でアドレスをテレフォニーするため、さらにコールの試みを配置しようとするかどうかを指定します。 「再帰」の値が「はい」であれば、スクリプトに「リダイレクト」の出力が取られないことに注意してください。この場合、この出力は存在してはなりません。このパラメータのデフォルト値は「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".

第三オプションのパラメータは、「発注」です。 「平行」、「順次」、および「最初のみ」:これは3つの値を持つことができます。このパラメータは、ロケーションセットの位置が試されるべきどのような順序で指定します。パラレルは、それら全てが同時に試みられることを要求します。シーケンシャルは1つが成功するかセットが使い果たされるまで優先順位が最も高い一つは、等、最初に試み次に高い優先順位の第有するものとすることが求められます。まずのみのセットのみで、最も優先順位の高いアドレスを試し、その後、出力のいずれかを追跡するために、サーバーに指示します。 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.

プロキシ操作が完了すると、制御は、他のノードに渡された場合、使用されてきたすべてのロケーションは、ロケーションセットからクリアされます。 「順序」が「平行」または「順次」であった場合には、位置セットはproxyable位置の空です。 「順序」は「最初だけ」だった場合のセットで最も優先度の高い項目が集合から削除されます。 (全ての場合において、このような「HTTP」のURIなどの非proxyable位置が残る。)「リダイレクション」出力の場合には、コールがリダイレクトした新しいアドレスは、その後、位置セットに追加されます。

6.1.1. Usage of "proxy" with SIP
6.1.1. SIPと「プロキシ」の使い方

For SIP, the best response to a "proxy" node is determined by the algorithm of the SIP specification. The node's outputs correspond to the following events:


busy: A 486 or 600 response was the best response received for the call request.


redirection: A 3xx response was the best response received for the call request.


failure: Any other 4xx, 5xx, or 6xx response was the best response received for the call request.


no-answer: No final response was received for the call request before the timeout expired.


SIP servers SHOULD honor the "q" parameter of SIP registrations when determining location priority.


6.2. Redirect
6.2. リダイレクト

Redirect causes the server to direct the calling party to attempt to place its call to the currently specified set of locations. The syntax of this node is specified in Figure 13.


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


             Node:  "redirect"
          Outputs:  None         (No node may follow)
        Next node:  None
       Parameters:  "permanent"  Whether the redirection should be
                                 considered permanent

Figure 13: Syntax of the "redirect" node


Redirect immediately terminates execution of the CPL script, so this node has no outputs and no next node. It has one parameter, "permanent", which specifies whether the result returned should indicate that this is a permanent redirection. The value of this parameter is either "yes" or "no" and its default value is "no."


6.2.1. Usage of "redirect" with SIP
6.2.1. SIPと「リダイレクト」の使い方

The SIP server SHOULD send a 3xx class response to a call request upon executing a "redirect" tag. If "permanent" was "yes", the server SHOULD send the response "301" (Moved permanently), otherwise it SHOULD send "302" (Moved temporarily).

SIPサーバは、「リダイレクト」タグを実行時に呼び出し要求に対する3xxクラスの応答を送るべきです。 「永久」は「YES」であった場合は、サーバが「301」の応答を送信すべきである(恒久的に移動)、それ以外の場合は「302」(一時的に移動)を送信すべきです。

6.3. Reject
6.3. 拒絶します

Reject nodes cause the server to reject the call attempt. Their syntax is given in Figure 14. The specific behavior they invoke is dependent on the underlying signalling protocol involved, though their semantics are generally applicable.


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

Figure 14: Syntax of the "reject" node


A reject node immediately terminates the execution of a CPL script, so this node has no outputs and no next node.


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

「ステータス」と「理由」:このノードは2つの引数を持っています。 「状態」引数は必要とされ、値「ビジー」、「NOTFOUND」、「拒否」、「エラー」、またはシグナリングプロトコルに定義された状態のいずれかをとることができます。

The "reason" argument optionally allows the script to specify a reason for the rejection.


6.3.1. Usage of "reject" with SIP
6.3.1. SIPと「拒否」の使い方

Servers which implement SIP SHOULD also allow the "status" field to be a numeric argument corresponding to a SIP status in the 4xx, 5xx, or 6xx range.


They SHOULD send the "reason" parameter in the SIP reason phrase.


A suggested mapping of the named statuses is as follows. Servers MAY use a different mapping, though similar semantics SHOULD be preserved.


"busy": 486 Busy Here


"notfound": 404 Not Found


"reject": 603 Decline


"error": 500 Internal Server Error


7. Non-signalling Operations

In addition to the signalling operations, CPL defines several operations which do not affect and are not dependent on the telephony signalling protocol.


7.1. Mail
7.1. 郵便物

The mail node causes the server to notify a user of the status of the CPL script through electronic mail. Its syntax is given in Figure 15.


Node: "mail" Outputs: None (Next node follows directly) Next node: Any node Parameters: "url" Mailto url to which the mail should be sent


Figure 15: Syntax of the "mail" node


The "mail" node takes one argument: a "mailto" URL giving the address, and any additional desired parameters, of the mail to be sent. The server sends the message containing the content to the given url; it SHOULD also include other status information about the original call request and the CPL script at the time of the notification.


Using a full "mailto" URL rather than just an e-mail address allows additional e-mail headers to be specified, such as <mail url="" />.

<:/「?=ルック%20failed jones@example.com対象のmailto」メールURL =>フル「のmailto」URLだけではなく、電子メールアドレスを使用すると、追加の電子メールヘッダのような、指定することができます。

A mail node has only one possible result, since failure of e-mail delivery cannot reliably be known in real time. Therefore, its XML representation does not have output tags: the <mail> tag directly contains another node tag.


Note that the syntax of XML requires that ampersand characters, "&", which are used as parameter separators in "mailto" URLs, be quoted as "&amp;" inside parameter values (see Section C.12 of the XML specification [2]).

XMLの構文は、「MAILTO」のURLにパラメータの区切りとして使用されているアンパサンド文字は、「&」、として引用されている必要があります「&#038;」パラメータ値内部(XML仕様のセクションC.12 [2]を参照)。

7.1.1. Suggested Content of Mailed Information
7.1.1. 郵送情報の推奨コンテンツ

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は、対象のヘッダを指定しなかった場合、電子メールの件名は、SIP要求の対象ヘッダに続く「[CPL]」です。 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.


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


4. If the "mailto" URI specifies a body, it is used. If none was specified, the body SHOULD contain at least the identity of the caller (both the caller's display name and address), the date and time of day, the call subject, and if available, the call priority.


The server SHOULD honor the user's requested languages, and send the mail notification using an appropriate language and character set.


7.2. Log
7.2. ログ

The Log node causes the server to log information about the call to non-volatile storage. Its syntax is specified in Figure 16.


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

Figure 16: Syntax of the "log" node


Log takes two arguments, both optional: "name", which specifies the name of the log, and "comment", which gives a comment about the information being logged. Servers SHOULD also include other information in the log, such as the time of the logged event, 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.

ログは、オプションの両方の、2つの引数を取ります。ログの名前を指定し、「名前」、および「コメント」を、ログに記録された情報についてのコメントを与えます。サーバはまた、などの他のこのようなログに記録されたイベントの時間としてログの情報、ログインするための呼び出しをトリガした情報、およびを含むべきです。ログは、イベントをログに記録するスクリプトの所有者に固有のものです。 「名前」パラメータが指定されていない場合、イベントはスクリプトの所有者のための標準的な、サーバーに定義されたログファイルに記録されます。この仕様は、ユーザーがサーバからログを取得する方法を定義しません。

The name of a log is a logical name only, and does not necessarily correspond to any physical file on the server. The interpretation of the log file name is server defined, as is a mechanism to access these logs. The CPL server SHOULD NOT directly map log names uninterpreted onto local file names, for security reasons, lest a security-critical file be overwritten.


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

正常に動作しCPLサーバーは、今までに失敗する「ログ」イベントを許してはなりません。そのため、ログのノードが唯一の可能な結果を​​持つことができ、そしてそのXML表現は、明示的な出力タグを持っていません。 CPL <ログ>タグは、直接他のノードのタグが含まれています。

8. Subactions
8. subactionibus

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


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


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

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


Figure 17: Syntax of subactions and "sub" pseudo-nodes


Subactions are defined through "subaction" tags. These tags are placed in the CPL script after any ancillary information (see Section 9), but before any top-level tags. They take one argument: "id", a token indicating a script-chosen name for the subaction. The "id" value for every "subaction" tag in a script MUST be unique within that script.

サブアクションは、「サブアクション」タグによって定義されています。これらのタグは任意の補助的な情報(セクション9を参照)した後、しかし、任意のトップレベルのタグの前にCPLスクリプトに配置されています。 「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.

サブアクションは、「サブ」タグから呼ばれています。 「サブ」タグは、「疑似ノード」であり、真のノードを使用することができるCPLアクションでどこでも使用することができます。これは、サブアクションの名前が呼ばれるように、一つのパラメータ、「参照」を取ります。 「サブ」タグは、それ自身の出力を含まず、代わりにサブアクションへのパスを制御します。

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.

サブアクションへの参照は、現在のアクションの前に定義されたサブアクションを参照する必要があります。 「サブ」タグは、それが中に表示される、または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.


Every sub MUST refer to a subaction ID defined within the same CPL script. No external links are permitted.


Subaction IDs are case sensitive.


If any subsequent version or extension defines external linkages, it should probably use a different tag, perhaps XLink [21]. Ensuring termination in the presence of external links is a difficult problem.


9. Ancillary Information

No ancillary information is defined in the base CPL specification. If ancillary information, not part of any operation, is found to be necessary for a CPL extension, it SHOULD be placed within this tag.


The (trivial) definition of the ancillary information tag is given in Figure 18.


It may be useful to include timezone definitions inside CPL scripts directly, rather than referencing them externally with "tzid" and "tzurl" parameters. If it is, an extension could be defined to include them here.


                            Tag:  "ancillary"
                     Parameters:  None
                        Subtags:  None

Figure 18: Syntax of the "ancillary" tag


10. Default Behavior

When a CPL node reaches an unspecified output, either because the output tag is not present, or because the tag is present but does not contain a node, the CPL server's behavior is dependent on the current state of script execution. This section gives the operations that should be taken in each case.


no location modifications or signalling operations performed, location set empty: Look up the user's location through whatever mechanism the server would use if no CPL script were in effect. Proxy, redirect, or send a rejection message, using whatever policy the server would use in the absence of a CPL script.


no location modifications or signalling operations performed, location set non-empty: (This can only happen for outgoing calls.) Proxy the call to the addresses in the location set.


location modifications performed, no signalling operations: Proxy or redirect the call, whichever is the server's standard policy, to the addresses in the current location set. If the location set is empty, return a "notfound" rejection.


noanswer output of proxy, no timeout given: (This is a special case.) If the "noanswer" output of a proxy node is unspecified, and no timeout parameter was given to the proxy node, the call should be allowed to ring for the maximum length of time allowed by the server (or the request, if the request specified a timeout).


proxy operation previously taken: Return whatever the "best" response is of all accumulated responses to the call to this point, according to the rules of the underlying signalling protocol.


11. CPL Extensions
11. CPL拡張

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


CPL extensions are indicated by XML namespaces [11]. Every extension MUST have an appropriate XML namespace assigned to it. The XML namespace of the extension MUST be different from the XML namespace defined in Section 14. The extension MUST NOT change the syntax or semantics of the CPL schema defined in this document. All XML tags and attributes that are part of the extension MUST be appropriately qualified so as to place them within that namespace.


Tags or attributes in a CPL script which are in the global namespace (i.e., not associated with any namespace) are equivalent to tags and attributes in the CPL namespace "urn:ietf:params:xml:ns:cpl".


A CPL script SHOULD NOT specify any namespaces it does not use. For compatibility with non-namespace-aware parsers, a CPL script MAY omit the base CPL namespace for a script which does not use any extensions.


A CPL server MUST reject any script containing a reference to a namespace it does not understand. It MUST reject any script containing an extension tag or attribute that is not qualified to be in an appropriate namespace.


A syntax such as


<extension-switch> <extension has=""> [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.

拡張子を処理する別の方法として提案されました。これは、何らかの形で、サーバーがサポートする拡張モジュールをするかを決定するためのスクリプトの作者を必要とせずに、スクリプトをサーバにアップロードすることが可能となります。しかし、他の言語の開発経験、特にふるい[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 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のXMLスキーマでは、我々はそれに応じて、抽象型「TopLevelActionType」、「SWITCHTYPE」、および「ACTIONTYPE」を持っている3つの抽象要素、すなわち「toplevelaction」、「スイッチ」、および「アクション」を紹介します。 CPL拡張の任意のトップレベルのアクションは、抽象「toplevelaction」要素ののsubstitutionGroupとして定義されなければならない、とタイプが「TopLevelActionType」から延びています。 CPL拡張のいずれかのスイッチは、抽象「スイッチ」要素のsubstitutionGroupとして定義されなければならない、とタイプが「SWITCHTYPE」から延びています。 CPL拡張の任意のアクションは、抽象「作用」要素ののsubstitutionGroupとして定義されなければならない、とタイプが「ACTIONTYPE」から延びています。

12. Examples
12.1. Example: Call Redirect Unconditional
12.1. 例:リダイレクト無条件に電話

The script in Figure 19 is a simple script that redirects all calls to a single fixed location.


<?xml version="1.0" encoding="UTF-8"?> <cpl xmlns="urn:ietf:params:xml:ns:cpl" xmlns:xsi="" xsi:schemaLocation="urn:ietf:params:xml:ns:cpl cpl.xsd "> <incoming> <location url=""> <redirect/> </location> </incoming> </cpl>

<?xml version = "1.0" エンコード= "UTF-8"?> <CPLののxmlns = "壷:IETF:のparams:XML:NS:CPL" のxmlns:XSI = " / XMLスキーマ・インスタンス」のxsi:のschemaLocation = "URN:IETF:paramsは:XML:NS:CPL cpl.xsd "> <着信> <場所のURL =""> <リダイレクト/> < /場所> </着信> </ CPL>

Figure 19: Example Script: Call Redirect Unconditional


12.2. Example: Call Forward Busy/No Answer
12.2. 例:ビジー電話転送/無回答

The script in Figure 20 illustrates some more complex behavior. We see an initial proxy attempt to one address, with further operations if that fails. We also see how several outputs take the same action subtree, through the use of subactions.


<?xml version="1.0" encoding="UTF-8"?> <cpl xmlns="urn:ietf:params:xml:ns:cpl" xmlns:xsi="" xsi:schemaLocation="urn:ietf:params:xml:ns:cpl cpl.xsd "> <subaction id="voicemail"> <location url=""> <proxy/> </location> </subaction> <incoming> <location url=""> <proxy timeout="8"> <busy> <sub ref="voicemail"/> </busy> <noanswer> <sub ref="voicemail"/> </noanswer> </proxy> </location> </incoming> </cpl>

<?xml version = "1.0" エンコード= "UTF-8"?> <CPLののxmlns = "壷:IETF:のparams:XML:NS:CPL" のxmlns:XSI = " / XMLスキーマ・インスタンス」のxsi:のschemaLocation = "URN:IETF:paramsは:XML:NS:> ":CPLは "> <サブアクションID =" ボイスメール"> <場所のURL =" SIPをcpl.xsd <プロキシ/> </場所> </サブアクション> <着信> <場所のURL = ""> <ビジー> <サブREF = "ボイスメール" <= "8" プロキシタイムアウト> / > </ビジー> <noanswer> <サブREF = "ボイスメール" /> </ noanswer> </プロキシ> </場所> </着信> </ CPL>

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


12.3. Example: Call Forward: Redirect and Default
12.3. 例:リダイレクトとデフォルト:電話転送

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="" xsi:schemaLocation="urn:ietf:params:xml:ns:cpl cpl.xsd "> <incoming> <location url=""> <proxy> <redirection> <redirect/> </redirection> <default> <location url=""> <proxy/> </location> </default> </proxy> </location> </incoming> </cpl>

<?xml version = "1.0" エンコード= "UTF-8"?> <CPLののxmlns = "壷:IETF:のparams:XML:NS:CPL" のxmlns:XSI = " / XMLスキーマ・インスタンス」のxsi:のschemaLocation = "URN:IETF:paramsは:XML:NS:CPL cpl.xsd "> <着信> <場所のURL =""> <プロキシ> <リダイレクト> <リダイレクト/> </リダイレクト> <デフォルト> <場所のurl = "一口"> <プロキシ/> </場所> </デフォルト> </プロキシ> </場所> </入> </ CPL>

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


12.4. Example: Call Screening
12.4. 例:通話スクリーニング

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


<?xml version="1.0" encoding="UTF-8"?> <cpl xmlns="urn:ietf:params:xml:ns:cpl" xmlns:xsi="" 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" エンコード= "UTF-8"?> <CPLののxmlns = "壷:IETF:のparams:XML:NS:CPL" のxmlns:XSI = " / XMLスキーマ・インスタンス "のxsi:のschemaLocation = "URN:IETF:paramsは:XML:NS:CPL cpl.xsd "> <着信> <アドレス・スイッチ・フィールドは=" 原点" サブフィールドは= "ユーザ"> <アドレス=は" 匿名> "/> </アドレス> </アドレス・スイッチ> </入> </ CPL「理由=" 私は匿名のコールを拒否拒否 "> <ステータス=拒否"

Figure 22: Example Script: Call Screening


12.5. Example: Priority and Language Routing
12.5. 例:優先度と言語のルーティング

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


<?xml version="1.0" encoding="UTF-8"?> <cpl xmlns="urn:ietf:params:xml:ns:cpl" xmlns:xsi="" xsi:schemaLocation="urn:ietf:params:xml:ns:cpl cpl.xsd "> <incoming> <priority-switch> <priority greater="urgent"/> <otherwise> <language-switch> <language matches="es"> <location url=""> <proxy/> </location> </language> <otherwise> <location url=""> <proxy/> </location> </otherwise> </language-switch> </otherwise> </priority-switch> </incoming> </cpl>

<?xml version = "1.0" エンコード= "UTF-8"?> <CPLののxmlns = "壷:IETF:のparams:XML:NS:CPL" のxmlns:XSI = " / XMLスキーマ・インスタンス」のxsi:のschemaLocation = "URN:IETF:paramsは:XML:NS:CPL cpl.xsd "> <着信> <優先スイッチ> <優先大きく=" 緊急" /> <そうでない> <言語スイッチ> <言語マッチ= "ES"> <場所のurl = "一口"> <プロキシ/> </場所> </言語> <そう> <場所のURL = "一口:英語@演算子.example.comの "> <プロキシ/> </場所> </さもなければ> </言語スイッチ> </さもなければ> </優先スイッチ> </着信> </ CPL>

Figure 23: Example Script: Priority and Language Routing


12.6. Example: Outgoing Call Screening
12.6. 例:発信コールスクリーニング

The script in Figure 24 illustrates a script filtering outgoing calls, in the form of a script which prevent 1-900 (premium) calls from being placed. This script also illustrates subdomain matching.


<?xml version="1.0" encoding="UTF-8"?> <cpl xmlns="urn:ietf:params:xml:ns:cpl" xmlns:xsi="" 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" エンコード= "UTF-8"?> <CPLののxmlns = "壷:IETF:のparams:XML:NS:CPL" のxmlns:XSI = " / XMLスキーマ・インスタンス」のxsi:のschemaLocation = "URN:IETF:paramsは:XML:NS:CPLのcpl.xsd "> <発信> <アドレス・スイッチ・フィールド=" オリジナル先" サブフィールド= "TEL"> <アドレスsubdomain-の= "1900"> <ステータス= "拒否" 拒絶理由= "未1-900電話をかけることができました。" /> </アドレス> </アドレス・スイッチ> </送信> </ CPL>

Figure 24: Example Script: Outgoing Call Screening


12.7. Example: Time-of-day Routing
12.7. 例:time-of-dayルーティング

Figure 25 illustrates time-based conditions and timezones.


<?xml version="1.0" encoding="UTF-8"?> <cpl xmlns="urn:ietf:params:xml:ns:cpl" xmlns:xsi="" xsi:schemaLocation="urn:ietf:params:xml:ns:cpl cpl.xsd "> <incoming> <time-switch tzid="America/New_York" tzurl=""> <time dtstart="20000703T090000" duration="PT8H" freq="weekly" byday="MO,TU,WE,TH,FR"> <lookup source="registration"> <success> <proxy/> </success> </lookup> </time> <otherwise> <location url=""> <proxy/> </location> </otherwise> </time-switch> </incoming> </cpl>

<?xml version = "1.0" エンコード= "UTF-8"?> <CPLののxmlns = "壷:IETF:のparams:XML:NS:CPL" のxmlns:XSI = " / XMLスキーマ・インスタンス "のxsi:schemaLocationの= "壷:IETF:のparams:XML:NS:CPLのcpl.xsd "> <入> <タイムスイッチTZID =" アメリカ/ニューヨーク" tzurl =" のhttp://zones.example .COM / TZ /アメリカ/ニューヨーク "> <時間DTSTART =" 20000703T090000" 期間= "PT8H" FREQ = "毎週" BYDAY = "MO、TU、WE、TH、FR"> <参照元= "登録"> <成功> <プロキシ/> </成功> </ルックアップ> </時間> <そう> <場所のURL = "一口"> <プロキシ/> </場所> </そうでありません> < /タイムスイッチ> </着信> </ CPL>

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


12.8. Example: Location Filtering
12.8. 例:場所のフィルタリング

Figure 26 illustrates filtering operations on the location set. In this example, we assume that version 0.9beta2 of the "Inadequate Software SIP User Agent" mis-implements some features, and so we must work around its problems. We know that it cannot talk successfully to one particular mobile device we may have registered, so we remove that location from the location set. Once this operation has been completed, call setup is allowed to proceed normally.


<?xml version="1.0" encoding="UTF-8"?> <cpl xmlns="urn:ietf:params:xml:ns:cpl" xmlns:xsi="" 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=""> <proxy/> </remove-location> </success> </lookup> </string> </string-switch> </incoming> </cpl>

<?xml version = "1.0" エンコード= "UTF-8"?> <CPLののxmlns = "壷:IETF:のparams:XML:NS:CPL" のxmlns:XSI = " / XMLスキーマ・インスタンス "のxsi:のschemaLocation = "URN:IETF:paramsは:XML:NS:CPL cpl.xsd "> <着信> <文字列スイッチフィールド=" ユーザエージェント"> <文字列=は" 不適切なソフトウェアSIPユーザエージェント/ 0.9beta2 "> <参照元=" 登録 "> <成功> <削除-場所場所=" "> <プロキシ/> </削除-場所> </成功> < /検索> </文字列> </文字列スイッチ> </入> </ CPL>

Figure 26: Example Script: Location Filtering


12.9. Example: Non-signalling Operations
12.9. 例:非シグナリング操作

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="" xsi:schemaLocation="urn:ietf:params:xml:ns:cpl cpl.xsd "> <incoming> <lookup source="" timeout="8"> <success> <proxy/> </success> <failure> <mail url=""/> </failure> </lookup> </incoming> </cpl>

<?xml version = "1.0" エンコード= "UTF-8"?> <CPLののxmlns = "壷:IETF:のparams:XML:NS:CPL" のxmlns:XSI = " / XMLスキーマ・インスタンス "のxsi:のschemaLocation =" URN:IETF:paramsは:XML:NS:CPL cpl.xsd "> <着信> <ルックアップ・ソース="。 CGIユーザー=メアリー」タイムアウト= "8"> <成功> <プロキシ/> </成功> <失敗> <メールURL = "mailtoの:??mary@example.com対象=ルック%20failed" /> </失敗> </参照> </入> </ CPL>

Figure 27: Example Script: Non-signalling Operations


12.10. Example: Hypothetical Extensions
12.10. 例:仮説の拡張機能

The example in Figure 28 shows a hypothetical extension that implements distinctive ringing. The XML namespace "" specifies a new node named "ring".

図28の例では、呼び出し音を実装する仮想的な拡張を示します。 XML名前空間「は、」「リング」という名前の新しいノードを指定します。

<?xml version="1.0" encoding="UTF-8"?> <xs:schema targetNamespace="" xmlns="" xmlns:xsi="" xmlns:xs="" 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" エンコード= "UTF-8"?> <XS:スキーマのtargetNamespace = "" のxmlns = " /独特のリング "のxmlns:XSI = "" のxmlns:XS = "" のxmlns:CPL =" URN:IETF:のparams:XML:NS:CPL」のelementFormDefault = "資格" attributeFormDefault = "非修飾"> <XS:インポートの名前空間= "壷:IETF:のparams:XML:NS:CPL" のschemaLocation = "cpl.xsd" / > <XS:complexTypeの名前= "DRingAction"> <XS:complexContentを> <XS:増設ベース= "CPL:ACTIONTYPE"> <XS:属性名= "ringstyle" タイプ= "XS:文字列" 使用= "オプション" / > </ XS:拡張> </ XS:complexContentを> </ XS:complexTypeの> <XS:要素名= "リング" タイプ= "DRingAction" のsubstitutionGroup = "CPL:アクション" /> </ XS:スキーマ>

<?xml version="1.0" encoding="UTF-8"?> <cpl xmlns="urn:ietf:params:xml:ns:cpl" xmlns:dr="" xmlns:xsi="" xsi:schemaLocation="urn:ietf:params:xml:ns:cpl cpl.xsd distinctive-ring.xsd"> <incoming> <address-switch field="origin"> <address is=""> <dr:ring ringstyle="warble"/> </address> </address-switch> </incoming> </cpl>

<?xml version = "1.0" エンコード= "UTF-8"?> <CPLのxmlns = "壷:IETF:のparams:XML:NS:CPL" のxmlns:DR = " "XSI:のschemaLocation = "壷:IETF:のparams:XML:NS:CPL cpl.xsdます。http://www.example:" XSI =のxmlns" を-ring .COM /独特リング独特-ring.xsd "> <着信> <アドレス・スイッチ・フィールド=" オリジン "> <アドレス=である" "> <DR:リングringstyleは=" "さえずり/ > </アドレス> </アドレススイッチ> </着信> </ CPL>

Figure 28: Example Schema and Script: Hypothetical Distinctive-Ringing Extension


The example in Figure 29 implements a hypothetical new attribute for address switches, to allow regular-expression matches. It defines a new attribute "regex" for the standard "address" node.


<?xml version="1.0" encoding="UTF-8"?> <cpl xmlns="urn:ietf:params:xml:ns:cpl" xmlns:xsi="" xsi:schemaLocation="urn:ietf:params:xml:ns:cpl cpl.xsd "> <incoming> <address-switch field="origin" subfield="user" xmlns:re=""> <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" エンコード= "UTF-8"?> <CPLののxmlns = "壷:IETF:のparams:XML:NS:CPL" のxmlns:XSI = " / XMLスキーマ・インスタンス "のxsi:のschemaLocation = "URN:IETF:paramsは:XML:NS:CPL cpl.xsd "> <着信> <アドレス・スイッチ・フィールド=" オリジン" サブフィールド= "ユーザー" のxmlns:=再" HTTP: // "> <アドレス再:正規表現="(。。。。*スミス| *・ジョーンズ)私はスミスに話をしたくない "> <拒否状態=" 拒否 "=理由"または幸せがおカネで買えるワケ "/> </アドレス> </アドレス・スイッチ> </入> </ CPL>

Figure 29: Example Script: Hypothetical Regular-Expression Extension


12.11. Example: A Complex Example
12.11. 例:複雑な例

Finally, Figure 30 is a complex example which shows the sort of sophisticated behavior that can be achieved by combining CPL nodes. In this case, the user attempts to have his calls reach his desk; if he does not answer within a small amount of time, calls from his boss are forwarded to his mobile phone, and all other calls are directed to voicemail. If the call setup failed, no operation is specified, so the server's default behavior is performed.


<?xml version="1.0" encoding="UTF-8"?> <cpl xmlns="urn:ietf:params:xml:ns:cpl" xmlns:xsi="" xsi:schemaLocation="urn:ietf:params:xml:ns:cpl cpl.xsd "> <subaction id="voicemail"> <location url=""> <redirect /> </location> </subaction> <incoming> <location url=""> <proxy timeout="8"> <busy> <sub ref="voicemail" /> </busy> <noanswer> <address-switch field="origin"> <address is=""> <location url="tel:+19175551212"> <proxy /> </location> </address> <otherwise> <sub ref="voicemail" /> </otherwise> </address-switch> </noanswer> </proxy> </location> </incoming> </cpl>

<?xml version = "1.0" エンコード= "UTF-8"?> <CPLののxmlns = "壷:IETF:のparams:XML:NS:CPL" のxmlns:XSI = " / XMLスキーマ・インスタンス」のxsi:のschemaLocation = "URN:IETF:paramsは:XML:NS:> ":CPLは "> <サブアクションID =" ボイスメール"> <場所のURL =" SIPをcpl.xsd <リダイレクト/> </場所> </サブアクション> <着信> <場所のURL = ""> <プロキシタイムアウト= "8"> <ビジー> <サブREF = "ボイスメール" / > </忙しい> <noanswer> <アドレス・スイッチフィールド= "起源"> <アドレスです= ""> <場所のURL = "TEL:19175551212"> <プロキシ/> </場所> </アドレス> <そうでない> <サブREF = "ボイスメール" /> </さもなければ> </アドレススイッチ> </ noanswer> </プロキシ> </場所> </着信> </ CPL>

Figure 30: Example Script: A Complex Example


13. Security Considerations

CPL is designed to allow services to be specified in a manner which prevents potentially hostile or mis-configured scripts from launching security attacks, including denial-of-service attacks. Because script runtime is strictly bounded by acyclicity, and because the number of possible script operations are strictly limited, scripts should not be able to inflict damage upon a CPL server.


Because scripts can direct users' telephone calls, the method by which scripts are transmitted from a client to a server MUST be strongly authenticated. Such a method is not specified in this document.


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


14. IANA Considerations
14. IANAの考慮事項

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

この文書は、新しいMIMEタイプ、アプリケーション/ CPL + XML、およびRFC 2141 [12]あたりの新しいURN、RFC 2648 [13]、およびRFC 3688 [14]を登録します。

The XML namespace urn:ietf:params:xml:ns:cpl will only refer to the version of CPL in this document and will not change. Any CPL enhancements MUST be made by extensions and MUST have different namespaces.


14.1. URN Sub-Namespace Registration for urn:ietf:params:xml:ns:cpl
14.1. 骨壷のためのURNサブ名前空間の登録:IETF:のparams:XML:NS:CPL

URI: urn:ietf:params:xml:ns:cpl


Registrant Contact: Jonathan Lennox <> Xiaotao Wu <> Henning Schulzrinne <>

登録者連絡先:<。Huaguoshan .Columbiaこの時間制限@>ジョナサンレノックス<。レノックス@ .Columbiaこの時間制限> AOディアンW Uξ<。アモイネットワーク@この時点で.Columbia少量>ヘニング・シュルツの日も



           <?xml version="1.0"?>
           <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML Basic 1.0//EN"
           <html xmlns="">
             <meta http-equiv="content-type"
             <title>Call Processing Language Namespace</title>

<h1>Namespace for Call Processing Language</h1> <h2>urn:ietf:params:xml:ns:cpl</h2> <p><a href=""> RFC3880</a>.</p> </body> </html> END

<H1>コール処理言語のための名前空間</ H1> <H2> URN:IETF:のparams:XML:NS:CPL </ H2> <P> <のhref = "中・ノートRFC3880する</a> / rfc3880.txt ">。</ P> </ body> </ html>このEND

14.2. Schema registration
14.2. スキーマの登録

This specification registers XML Schema for CPL, as per the guidelines in [14].


URI: urn:ietf:params:xml:schema:cpl


Registrant contact: Jonathan Lennox <> Xiaotao Wu <> Henning Schulzrinne <>

登録者連絡先:<。Huaguoshan .Columbiaこの時間制限@>ジョナサンレノックス<。レノックス@ .Columbiaこの時間制限> AOディアンW Uξ<。アモイネットワーク@この時点で.Columbia少量>ヘニング・シュルツの日も

XML: The XML can be found in Appendix C.


14.3. MIME Registration
14.3. MIME登録

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 subtype name: cpl+xml

MIMEサブタイプ名:CPL + xmlの

Mandatory parameters: none


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

オプションのパラメータ:RFC 3023でアプリケーション/ XML用として文字セット。

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

エンコードの考慮事項:RFC 3023でアプリケーション/ XMLのよう。

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

セキュリティの考慮事項:第13節、およびRFC 3023のセクション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.


Published specification: This document.


Applications which use this media type: SIP proxy servers and other telephony servers, and client software to control their behavior.


Additional information:


Magic number: None


File extension: .cpl or .xml


Macintosh file type code: "TEXT"


Person and e-mail address for further information: Jonathan Lennox <> Xiaotao Wu <> Henning Schulzrinne <>

詳細については、人と電子メールアドレス:ジョナサン・レノックス<> Xiaotao呉<>ヘニングSchulzrinneと<>

Intended usage: COMMON


Author/Change Controller: The IETF.


15. Acknowledgments

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

この文書は、審査やIETF IPテレフォニーワーキンググループによって時にコメントしました。我々は、特に彼らの助けのために、次の人を認めます:

The outgoing call screening script was written by Kenny Hom.


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


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

タイムスイッチ部のテキストは、フランク・ドーソンとDerik Stenersonにより、[8] RFC 2445から(軽く修飾)しました。

We drew a good deal of inspiration, notably the language's lack of Turing-completeness and the syntax of string matching, from the specification of Sieve [22], a language for user filtering of electronic mail messages.


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


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


A. An Algorithm for Resolving Time Switches


The following algorithm determines whether a given instant falls within a repetition of a "time-switch" recurrence. If the pre-processing described in Section 4.4.1 has been done, it operates in constant time. Open-source Java code implementing this algorithm is available at on the world wide web.

以下のアルゴリズムは、与えられた瞬間は「時間スイッチ」再発の繰り返し内であるか否かを判定する。 4.4.1項で説明した前処理が行われた場合、それは一定の時間で動作します。このアルゴリズムを実装するオープンソースのJavaコードは、World Wide Web上ので入手可能です。

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

このアルゴリズムは正確であると考えられますが、このセクションは非規範的です。セクション4.4、及びRFC 2445 [8]、再発の決定的な定義です。

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


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

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


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

4.「byxxx」ルールまたはで指定された最小単位を決定し、「FREQ」をこの最小単位を呼び出します。以前の瞬間を決定する(前または通話時間に等しい)最小単位よりも小さいすべての時間単位がのものと同じである場合、「DTSTART。」最小単位は秒である場合、この時間は、インスタントと同じです。最小単位は分または時間である場合、数分または数分と時間は、それぞれ、「DTSTART」と同じでなければなりません。他のすべての最小単位の場合は、時刻は同じでなければなりません「DTSTART。」最小単位が週の場合は、曜日が同じでなければなりません「DTSTART。」最小単位が月の場合は、その日の - 月と同じでなければならない「DTSTART。」最小単位が年の場合は、月と日のヶ月は、両方のと同じでなければならない「DTSTART。」 (これは、バックつ以上の最小単位をロールバックする必要があるかもしれ意味することに注意してください - 最小単位が月の場合は、その後、いくつかのヶ月は31日(または30日または29日)の日を持っていませんが、最小単位が年の場合、その後、何年かは、2月29日を持っていません。グレゴリオ暦では、最小単位は、最小単位が年の場合は8年の月である場合、または2ヶ月以上をロールバックすることは決して必要である。1904年と2096年の間に、4年以上にロールバックするために必要なことはありません - グレゴリオ暦はうるう年「スキップ」とき8年間のロールバックにのみ発生する可能性があります。

Call this instant the Candidate Start Time.


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


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


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


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


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


B. Suggested Usage of CPL with H.323


This appendix gives a suggested usage of CPL with H.323 [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を開発したITUの研究グループ16は、そのプロトコルの公式CPLのマッピング上で動作することを提案しています。したがって、このセクションは規範的ではありません。

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

B.1。 H.323と「アドレス・スイッチ」の使い方

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


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

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.


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サーバのために定義されています。可能な値は、 "あるdialedDigits"、 "H323-ID"、 "URL-ID"、 "transportID"、 "電子メール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のバージョンでは、「あるdialedDigits」が「E164」として知られていました。 2人の名前が同義語として扱われるべきです。

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.

エイリアスタイプは「URL-ID」で、URLスキームはH323以外のものでない限り、H.323メッセージの値が「アドレス型」のサブフィールドは、「H323」です。 SIPについては、セクション4.1.1に指定されている。この場合、アドレス型は、URLスキームです。

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


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


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

あるdialedDigits、partyNumber、mobileUIM、及びQ.931IE:「全アドレス」形であるように、「TEL」と「ユーザ」サブフィールドは、数字の文字列です。 「ホスト」と「ポート」サブフィールドは存在しません。

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


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


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

電子メールIDは:「ユーザー」と「ホスト」のサブフィールドは、メールアドレスの対応する部分に設定されています。 「ポート」と「TEL」サブフィールドは存在しません。 「全体のアドレス」フォームには、全体の電子メールアドレスに対応しています。

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

標準IPv4またはIPv6のテキスト表現に翻訳TransportAddressタイプである場合、「ipAddressの」、「ipSourceRoute」または「ip6Address」、「ホスト配列のIP」要素「サブフィールドに設定されている」、と:transportID 「ポート」サブフィールドは小数で表される配列の「ポート」の要素に設定されています。 「TEL」と「ユーザー」のフィールドは存在しません。 「全体のアドレス」の形式が定義されていません。表現とトランスポートアドレスのマッピングは、非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スキームを定義します。 4.1節で与えられたように、この付録では、CPL「アドレススイッチ」のサブフィールド上にこれらのURIのマッピングを定義します。この定義はまた、H.323仕様からの抜粋であるRFC 3508 [24]として利用可能です。

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.

H323のURIについては、「ユーザー」、「ホスト」、および「ポート」サブフィールドは、H.323のURLの対応する部分に設定されています。 「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でH323のURI「URL-ID」アドレスの別名のため、およびSIPメッセージ内H323 URIのために使用されるかもしれません。

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

B.2。 H.323と「文字列スイッチ」の使い方

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


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

「表示」IEは、従来ので、フィールド「発信者」と「アドレス一致」の「表示」サブフィールドにマッピングされなければならない間違いなく、発信者IDのために使用されます。しかしながら、A)は、メッセージ・レベルの情報要素ではなく、アドレスレベル1、およびb)Q.931仕様[23] [t]が表示情報要素の彼の目的は、ディスプレイを供給することであるのみ」と言うありますユーザーが表示することができる情報は、代わりに文字列スイッチ 『」にマッチできるようにするために、より適切であると考えられます』。

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

B.3。 H.323と「言語切り替え」の使い方

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

「言語切り替え」スイッチ用の言語の範囲は、H.323 UUIE「言語」から取得されます。最初のメッセージがこのUUIEを含んでいなかった場合、スイッチは、存在しません。

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

B.4。 H.323と「優先スイッチ」の使い方

All H.323 messages are considered to have priority "normal" for the purpose of a priority switch (see Section 4.5).


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

B.5。 H.323と「場所」の使い方

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


Specifications of other H.323 address alias types will require a CPL extension (see Section 11).


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

B.6。 H.323での「検索」の使い方

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


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

B.7。 H.323と「削除-場所」の使い方

Location removal nodes (Section 5.3) remove addresses with the alias type "url-ID" using verbatim string matching on the URLs. If a "tel" URL is specified as the location, matching addresses (ignoring visual separators) with the alias types "dialedDigits" ("e164"), "partyNumber", "mobileUIM", or "Q.931IE" are also removed. No mechanism is provided to remove other alias types.

場所除去ノード(5.3節)エイリアスタイプ「URL-ID」のURLにマッチする逐語的文字列を使用してアドレスを削除してください。 「TEL」URLは、「partyNumberは」エイリアスタイプ「あるdialedDigits」(「E164」)とアドレス(視覚セパレータを無視)と一致する、場所として指定されている場合、「mobileUIM」、または「Q.931IE」も除去されます。いかなるメカニズムは他の別名型を削除するために提供されていません。

C. The XML Schema for CPL


This section includes a full XML Schema describing the XML syntax of CPL. Every script submitted to a CPL server SHOULD comply with this XML Schema. When parsing scripts comply with the CPL DTD in earlier documents, the DOCTYPE lines in the scripts should be ignored. Note that compliance with this schema is not a sufficient condition for correctness of a CPL script, as many of the conditions described in this specification are not expressible in schema syntax. Figure 31 shows the structure of the schema. 'incoming' and 'outgoing' are defined as the substitutionGroup of the 'toplevelaction'. All the switches are defined as the substitutionGroup of the 'switch' element. All the actions are defined as the substitutionGroup of the 'action' element.

このセクションでは、CPLのXML構文を記述した完全なXMLスキーマが含まれています。 CPLサーバーに提出すべてのスクリプトは、このXMLスキーマに準拠すべきです。スクリプトは、以前の文書にCPL DTDに準拠して解析する場合には、スクリプト内でDOCTYPEの行は無視されなければなりません。本明細書に記載されている条件の多くは、スキーマ構文で表現されないようにこのスキーマに準拠は、CPLスクリプトの正当性のために十分な条件ではないことに留意されたいです。図31は、スキーマの構造を示します。 「着信」および「発信」「はtoplevelaction」ののsubstitutionGroupとして定義されます。すべてのスイッチは「スイッチ」要素ののsubstitutionGroupとして定義されています。すべてのアクションは「アクション」要素ののsubstitutionGroupとして定義されています。

         +---------+    +------+                    +--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        +------+ * +-----+    |
        ****  substitutes              * +-----+    |
                                       * +--------+ +-failure-Node
                                       **|redirect| |
                                       * +--------+ +-redirection-Node
                                       * +------+   |
                                        *|reject|   +-default-Node

Figure 31: The structure of the XML schema for CPL


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="" 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 <XS <xmlのバージョン= "1.0" エンコード= "UTF-8"?>:スキーマのtargetNamespace = "壷:IETF:のparams:XML:NS:CPL":IETF:のparams:XML:NS = "壷のxmlnsを: CPL」のxmlns:XS = "" のelementFormDefault = "資格" attributeFormDefault = "非修飾"> <XS:complexTypeの名= "TopLevelActionType" 抽象= "真"> <XS:グループREF = "ノード" /> </ XS:complexTypeの> <XS:要素名= "toplevelaction" タイプ= "TopLevelActionType" /> <XS:complexTypeの名= "ACTIONTYPE" 抽象= "真" /> <XS:要素名= "アクション" タイプ= "ACTIONTYPE" /> <XS:complexTypeの名= "SWITCHTYPE" 抽象= "真" /> <XS:要素名= "スイッチ" タイプ= "SWITCHTYPE" /> <XS:complexTypeの名= "ModifierType" 抽象= "TRUE" /> <XS:要素名= "修飾語" TYPE = "ModifierType" /> <XS:要素名= "位置" タイプ= "LocationType" のsubstitutionGroup = "改質" /> <XS:要素名= "ルックアップ" タイプ= "LookupType" のsubstitutionGroup = "改質" /> <XS:要素名= "削除ロケーションを" TYPE = "RemoveLocationType" のsubstitutionGroup = "改質" /> <XS:要素名= "サブ"タイプ= "サブアクション" /> <XS :グループ名= "ノード"> <XS:選択> <XS:要素REF = "スイッチ" のminOccurs = "0" のmaxOccurs = "1" /> <XS:要素REF = "改質" のminOccurs = "0" のmaxOccurs = "1" /> <XS:要素REF = "サブ" のminOccurs = "0" のmaxOccurs = "1" /> <XS:要素REF = "アクション" のminOccurs = "0" のmaxOccurs = "1" /> </ XS :選択> </ XS:グループ> <XS:complexTypeの名= "OtherwiseAction"> <XS:グループREF = "ノード" /> </ XS:complexTypeの> <XS:complexTypeの名= "NotPresentAction"> <XS:グループREF = "ノード" /> </ XS:complexTypeの> <XS:単純型名= "YesNoType"> <XS:制限ベース= "XS:NMTOKEN"> <XS:列挙値= "はい" /> <XS:列挙値= "NO" /> </ XS:制限> </ XS:単純> <XS:単純型名= "StatusType"> <XS:組合> <XS:単純> <XS:制限ベース= "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:列挙値= "ビジー" /> <XS:列挙値= "NOTFOUND" /> <XS:列挙値= "拒否" /> <XS:列挙値= "エラー" /> </ XS:制限> </ XS:単純> <XS:単純> <XS:制限ベース= "XS:文字列" /> </ XS:単純> </ XS:組合> </ XS:単純> <XS:単純型名= "OrderingType "> <XS:制限ベース=" XS:NMTOKEN "> <XS:列挙値=" 平行 "/> <XS:列挙値=" シーケンシャル "/> <XS:列挙値=" 最初のみ "/> < / XS:制限> </ XS:単純> <XS:単純型名= "AddressFieldType"> <XS:組合> <XS:単純> <XS:制限ベース= "XS:NMTOKEN"> <XS:列挙値=」原点 "/> <XS:列挙値=" 宛先 "/> <XS:列挙値=" オリジナル先 "/> </ XS:制限> </ XS:単純> <XS:単純> <XS:制限ベース= "XS:文字列" /> </ XS:単純> </ XS:組合> </ XS:単純> <XS:単純型名= "AddressSubfieldType"> <XS:組合> <XS:単純> <XS:制限基地= "XS:NMTOKEN"> <XS:列挙値= "アドレスタイプ" /> <XS:列挙値=「使用R "/> <XS:列挙値=" ホスト "/> <XS:列挙値=" ポート "/> <XS:列挙値=" TEL "/> <XS:列挙値=" 表示 "/> <XS :列挙値= "パスワード" /> <XS:列挙値= "エイリアス型" /> </ XS:制限> </ 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:単純> <XS:制限ベース= "XS:文字列" /> </ XS:単純> </ XS:組合> </ XS:単純> <XS:complexTypeの名= "AddressTypeに"> <XS:注釈> <XS:ドキュメント>の3つの属性のいずれか1つだけが</ XS表示される必要があります:ドキュメント> </ XS:注釈> <XS:グループREF = "ノード" /> <XS:属性名= "である" タイプ= "XS :文字列」使用= "オプション" /> <XS:属性名は= "のみ</ XS表示 ": "のドキュメント>> <XS::注釈> <XS" 文字列 "使用=" オプション" タイプ=" XSが含まれています:ドキュメント> </ XS:注釈> </ XS:属性> <XS:属性名= "サブドメインの" タイプ= "XS:文字列" 使用= "オプション"> <XS:注釈> <XS:ドキュメント>のために"ホスト"、 "TEL" のみ</ XS:ドキュメンテーション> </ XS:注釈> </ XS:属性> <XS:anyAttributeは名前空間= "##あらゆる" のprocessContents = "緩い" /> </ XS:complexTypeの> <XS:complexTypeの名前= "AddressSwitchType"> <XS:complexContentを> <XS:増設ベース= "SWITCHTYPE"> <XS:配列> <XS:要素名= "アドレス" タイプ= "AddressTypeに" のminOccurs = "0" maxOccurs属性XS /> <= "無制限":シーケンスのminOccurs = "0"> <XS:要素名= "ではない-PRES ENT」タイプ= "NotPresentAction" /> <XS:要素名= "アドレス" タイプ= "AddressTypeに" のminOccurs = "0" のmaxOccurs = "無制限" /> </ XS:配列> <XS:要素名= "そうでなければ"タイプ= "OtherwiseAction" のminOccurs = "0" /> </ XS:シーケンス> <XS:属性名= "フィールド" タイプ= "AddressFieldType" 使用= "必要" /> <XS:属性名= "サブフィールド" タイプ= "AddressSubfieldType" 使用= "オプション" /> </ XS:拡張> </ XS:complexContentを> </ XS:complexTypeの> <XS:要素名= "アドレス・スイッチ" タイプ= "AddressSwitchType" のsubstitutionGroup = "スイッチ" / >

<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:単純型名= "StringFieldType"> <XS:制限ベース= "XS:NMTOKEN"> <XS:列挙値= "被験者" /> <XS:列挙値= "組織" /> <XS:列挙値= "ユーザエージェント" /> <XS:列挙値= "表示" /> </ XS:制限> </ XS:単純> <XS:complexTypeの名= "StringType"> <XS:グループREF = "ノード" / > <XS:属性名= "である" タイプ= "XS:文字列" 使用= "オプション" /> <XS:属性名= "含む" タイプ= "XS:文字列" 使用= "オプション" /> <XS: anyAttributeは名前空間= "##あらゆる" のprocessContents = "緩い" /> </ XS:complexTypeの> <XS:complexTypeの名= "StringSwitchType"> <XS:complexContentを> <XS:増設ベース= "SWITCHTYPE"> <XS:シーケンス> <XS:要素名= "文字列" タイプ= "StringType" のminOccurs = "0" のmaxOccurs = "無制限" /> <XS:配列のminOccurs = "0"> <XS:要素名= "-存在しない" タイプ= "NotPresentAction" /> <XS:要素名= "文字列" タイプ= "StringType" のminOccurs = "0" のmaxOccurs = "無制限" /> </ XS:配列> <XS:要素名= "そうでなければ" タイプ= "OtherwiseAction "minOccurs属性=" 0 "/> </ XS:シーケンス> <XS:属性名=" フィールド "タイプ=" セントringFieldType」使用は= "必要"> <XS:注釈> <XS:ドキュメント>文字列は、大文字と小文字を区別しないUnicode文字列として一致している</ XS:ドキュメンテーション> </ XS:注釈> </ XS:属性> </ XS:拡張> </ XS:complexContentを> </ XS:complexTypeの> <XS:要素名= "文字列スイッチ" タイプ= "StringSwitchType" のsubstitutionGroup = "スイッチ" /> <XS:complexTypeの名前= "LanguageType"> <XS:グループREF =「ノード」/> <XS:属性名=「マッチ」タイプ=「XS:文字列」使用=> <XS「必要」:注釈が> <XS:>これらのパラメータの1つの値は、言語ドキュメントですRFC 3066で定義されて-tag、</ XS:ドキュメント>。</ XS:注釈>

</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:属性> <XS:anyAttributeは名前空間= "##あらゆる" のprocessContents = "緩い" /> </ XS:complexTypeの> <XS:complexTypeの名前= "LanguageSwitchType"> <XS:complexContentを> <XS:増設ベース= "SWITCHTYPE"> <XS:配列> <XS:要素名= "言語" タイプ= "LanguageType" のminOccurs = "0" のmaxOccurs = "無制限" /> <XS:配列のminOccurs = "0"> <XS:要素NAME = "-存在しない" タイプ= "NotPresentAction" /> <XS:要素名= "言語" タイプ= "LanguageType" のminOccurs = "0" のmaxOccurs = "無制限" /> </ XS:配列> <XS:要素NAME = "そうでなければ" タイプ= "OtherwiseAction" のminOccurs = "0" /> </ XS:配列> </ XS:拡張> </ XS:complexContentを> </ XS:complexTypeの> <XS:要素名= "、言語スイッチ "タイプ= "LanguageSwitchType" のsubstitutionGroup = "スイッチ"/> <XS:単純型名= "FreqType"> <XS:制限ベース= "XS:NMTOKEN"> <XS:パターン値=" [S | S] [E | E] [C | C] [O | O] [N | N] [D | D] [L | L] [Y | Y] "/> <XS:パターン値=" [M | M] [I | I] [N | N] [U | U] [T | T] [E | E] [L | L] [Y | Y] "/> <XS:パターン値=" [H | H] [O | O] [U | U] [R | R] [L | L] [Y | Y] "/> <XS:パターン値=" [D | D] [| A] [I | I] [L | L] [Y | Y] "/> <XS :パターン値= "[W | W] [E | E] [E | E] [K | K] [L | L] [Y | Y]" /> <XS:パターン値= "[M | M] [O | N] [N | N] [T | T] [H | H] [L | L] [Y | Y] "/> <XS:パターン値=" [Y | Y] [E | E] [| A] [R | R] [L | L] [Y | Y] "/> </ XS:制限> </ XS:単純> <XS:単純型名=" YearDayType "> <XS:組合> <XS:単純> <XS:制限ベース= "XS:整数"> <XS:のminInclusive値= " - 366" /> <XS:maxInclusiveを値= " - 1" /> </ XS:制限> </ XS :単純> <XS:単純> <XS:制限ベース= "XS:整数"> <XS:のminInclusive値= "1" /> <XS:maxExclusive値= "366" /> </ XS:制限> </ XS:単純> </ XS:組合>

</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:単純> <XS:単純型名= "DayType"> <XS:制限ベース= "XS:NMTOKEN"> <XS:パターン値= "[M | M] [O | O]" /> <XS :パターン値= "[T | T] [U | U]" /> <XS:パターン値= "[W | W] [E | E]" /> <XS:パターン値= "[T | T] [H | H] "/> <XS:パターン値=" [F | F] [R | R] "/> <XS:パターン値=" [S | S] [| A] "/> <XS :パターン値= "[S | S] [U | U]" /> </ XS:制限> </ XS:単純> <XS:complexTypeの名= "TimeType"> <XS:注釈> <XS:ドキュメント>正確に二つの属性「DTEND」と「継続」のいずれかが発生しなければなりません。 FREQが表示されない限り、FR​​EQを次の属性のいずれも意味がありません。 </ XS:ドキュメンテーション> </ XS:注釈> <XS:グループREF = "ノード" /> <XS:注釈> <XS::属性名= "DTSTART" タイプ= "XS文字列" 使用= "必要"> <XS:ドキュメント> RFC 2445 DATE-TIME </ XS:ドキュメンテーション> </ XS:注釈> </ XS:属性> <XS:属性名= "DTEND" タイプ= "XS:文字列" 使用= "オプション"> <XS:注釈> <XS:ドキュメント> RFC 2445 DATE-TIME </ XS:ドキュメンテーション> </ XS:注釈> </ XS:属性> <XS:属性名= "継続" タイプ= "XS:文字列" 使用= "オプション"> <XS:注釈> <XS:ドキュメント> RFC 2445 DURATION </ XS:ドキュメンテーション> </ XS:注釈> </ XS:属性> <XS:属性名= "FREQ" タイプ= "FreqType"属性名= "間隔" タイプ= "XS::POSITIVEINTEGER" デフォルト= "1" /> <XS:属性名=タイプ= "まで" "のxs:string" が使用= "オプション= "オプション"/> <XSを使用"> <XS:注釈> <XS:ドキュメント> RFC 2445 DATE-TIME </ XS:ドキュメンテーション> </ XS:注釈> </ XS:属性> <XS:属性名=" 数 "タイプ=" XS:POSITIVEINTEGER "使う=" オプション "/> <XS:属性名=" BYSECOND」タイプ= "XS:文字列" 使用= "オプション"> <XS:注釈> <XS:ドキュメント>秒以内のカンマ区切りリスト

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.

分。有効な値は0〜59です。</ XS:ドキュメント>。</ XS:注釈> </ XS:属性> <XS:属性名= "BYMINUTE" タイプ= "XS:文字列" 使用= "オプション"> <XS:注釈> <XS:時間以内分のドキュメント>カンマ区切りリスト。有効な値は0〜59です。</ XS:ドキュメント>。</ XS:注釈> </ XS:属性> <XS:属性名= "BYHOUR" タイプ= "XS:文字列" 使用= "オプション"> <XS:注釈> <XS:1日の時間のドキュメント>カンマ区切りリスト。有効な値は23に0をしている</ XS:ドキュメント>。</ XS:注釈> </ XS:属性> <XS:属性名= "BYDAY" タイプ= "XS:文字列" 使用= "オプション"> <XS:注釈> <XS:ドキュメント>曜日のカンマ区切りリスト。有効な値は、 "MO"、 "TU"、 "WE"、 "TH"、 "FR"、 "SA" と "SU" です。これらの値は、大文字と小文字は区別されません。それぞれは、正(+ N)または負(-n)整数が先行することができる</ XS:ドキュメント>。</ XS:注釈> </ XS:属性> <XS:属性名= "BYMONTHDAY" タイプ= "XSを:文字列」使用= 『オプション』> <XS:注釈> <XS:ドキュメント>月の日数のカンマ区切りリスト。有効な値は1から31にまたは-31 -1である。</ XS:ドキュメンテーション> </ XS:注釈> </ XS:属性> <XS:属性名は= "byyearday" タイプ= "XS:文字列" 使用=」オプション "> <XS:注釈> <XS:ドキュメント>今年の日のカンマ区切りリスト。有効な値は1から366にまたは-366です-1 </ XS:ドキュメント>。</ XS:注釈> </ XS:属性> <XS:属性名= "BYWEEKNO" タイプ= "XS:文字列" 使用=」オプション "> <XS:注釈> <XS:ドキュメント>年の週を指定する序数のカンマ区切りリスト。有効な値は-1に1 -53〜53かです。</ XS:ドキュメント>。</ XS:注釈> </ XS:属性> <XS:属性名= "BYMONTH" タイプ= "XS:文字列" 使用=」オプション "> <XS:注釈> <XS:ドキュメント>年の月のカンマ区切りリスト。

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>

有効な値は1〜12です。</ XS:ドキュメント>。</ XS:注釈> </ XS:属性> <XS:属性名= "のWkst" タイプ= "DayType" デフォルト= "MO" /> <XS:属性名前= "BYSETPOS" タイプ= "YearDayType" /> <XS:anyAttributeは名前空間= "##あらゆる" のprocessContents = "緩い" /> </ XS:complexTypeの> <XS:単純型名= "TZIDType"> <XS:制限基地= "XS:文字列" /> </ XS:単純> <XS:単純型名= "TZURLType"> <XS:制限ベース= "XS:anyURIの" /> </ XS:単純> <XS:complexTypeの名前= "TimeSwitchType"> <XS:complexContentを> <XS:増設ベース= "SWITCHTYPE"> <XS:配列> <XS:要素名= "時間" タイプ= "TimeType" のminOccurs = "0" のmaxOccurs = "無制限" /> <XS:配列のminOccurs = "0"> <XS:要素名= "-存在しない" タイプ= "NotPresentAction" /> <XS:要素名= "時間" タイプ= "TimeType" のminOccurs = "0" のmaxOccurs =」無制限 "/> </ XS:シーケンス> <XS:要素名=" それ以外 "タイプ= "OtherwiseAction" のminOccurs = "0"/> </ XS:シーケンス> <XS:属性名= "TZID" タイプ=" TZIDType "/> <XS:属性名=" tzurl」タイプ= "TZURLType" /> </ XS:拡張> </ XS:complexConten T> </ XS:complexTypeの> <XS:要素名= "タイムスイッチ" タイプ= "TimeSwitchType" のsubstitutionGroup = "スイッチ" /> <XS:simpleTypeの名前= "PriorityValues"> <XS:制限基地= "XS: NMTOKEN "> <XS:パターン値=" [E | E] [M | M] [E | E] [R | R] [G | G] [E | E] [N | N] [C | C] [Y | Y] "/> <XS:パターン値=" [U | U] [R | R] [G | G] [E | E] [N | N] [T | T] "/> <XS :パターン値= "[N | N] [O | O] [R | R] [M | M] [| A] [L | L]" /> <XS:パターン値= "[N | N] [O | O] [N | N] - [U | U] [R | R] [G | G] [E | E] [N | N] [T | T] "/> </ XS:制限> </ XS:単純> <XS:complexTypeの名前= "PriorityType"> <XS:注釈> <XS:ドキュメント>正確に3つの属性のいずれかが表示されなければなりません。</ XS:ドキュメントを>

</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:注釈> <XS:グループREF = "ノード" /> <XS:属性名= "少ない" タイプ= "PriorityValues" /> <XS:属性名= "大きい" タイプ= "PriorityValues" /> < XS:属性名= "等しい" タイプ= "XS:文字列"> <XS:注釈> <XS:ドキュメント>大文字と小文字を区別しない</ XS:ドキュメンテーション> </ XS:注釈> </ XS:属性> <XS: anyAttributeは名前空間= "##あらゆる" のprocessContents = "緩い" /> </ XS:complexTypeの> <XS:complexTypeの名前= "PrioritySwitchType"> <XS:complexContentを> <XS:増設ベース= "SWITCHTYPE"> <XS:シーケンス> <XS:要素名= "優先" タイプ= "PriorityType" のminOccurs = "0" のmaxOccurs = "無制限" /> <XS:配列のminOccurs = "0"> <XS:要素名= "-存在しない" タイプ= "NotPresentAction" /> <XS:要素名= "優先" タイプ= "PriorityType" のminOccurs = "0" のmaxOccurs = "無制限" /> </ XS:配列> <XS:要素名= "そうでなければ" タイプ= "OtherwiseAction "のminOccurs =" 0 "/> </ XS:配列> </ XS:拡張> </ XS:complexContentを> </ XS:complexTypeの> <XS:要素名=" 優先スイッチ」タイプ= "PrioritySwitchType" のsubstitutionGroup = "スイッチ" /> <XS:単純型名= "L ocationPriorityType "> <XS:制限ベース=" XS:フロート "> <XS:のminInclusive値=" 0.0 "/> <XS:maxInclusiveを値=" 1.0" /> </ XS:制限> </ XS:simpleTypeの> < XS:complexTypeの名前= "LocationType"> <XS:complexContentを> <XS:増設ベース= "ModifierType"> <XS:グループREF = "ノード" /> <XS:属性名= "URL" タイプ= "XS:anyURIの"使う=" 必須 "/> <XS:属性名=" 優先順位」タイプ= "LocationPriorityType" 使用= "オプションの" デフォルト= "1.0" /> <XS:属性名= "クリア" タイプ= "YesNoType" デフォルト= "ノー" /> </ XS:拡張> </ XS:complexContentを> </ XS:complexTypeの> <XS:complexTypeの名= "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:拡張ベース= "ModifierType"> <XS:すべて> <XS:要素名= "成功" のminOccurs = "0"> <XS:complexTypeの> <XS:グループREF = "ノード" / > </ XS:complexTypeの> </ XS:要素> <XS:要素名= "NOTFOUND" のminOccurs = "0"> <XS:complexTypeの> <XS:グループREF = "ノード" /> </ XS:complexTypeの> </ XS:要素> <XS:要素名= "失敗" のminOccurs = "0"> <XS:complexTypeの> <XS:グループREF = "ノード" /> </ XS:complexTypeの> </ XS:要素> < / XS:すべて> <XS:属性名= "ソース" タイプ= "XS:文字列" 使用= "必須" /> <XS:属性名は= "タイムアウト" タイプ= "XS:POSITIVEINTEGER" デフォルト= "30" / > <XS:属性名= "クリア" タイプ= "YesNoType" デフォルト= "なし" /> </ XS:拡張> </ XS:complexContentを> </ XS:complexTypeの> <XS:complexTypeの名= "RemoveLocationType"> <XS:complexContentを> <XS:拡張ベースは= "ModifierType"> <XS:グループREF = "ノード" /> <XS:属性名= "位置" タイプ= "XS:文字列" 使用= "オプション" /> < / XS:拡張> </ XS:complexContentを> </ XS:complexTypeの> <XS:complexTypeの名前= "LogActionメソッド"> <XS:complexContentを> <XS:増設ベース= "ACTIONTYPE"> <XS:グループREF = "ノード" /> <XS:属性名= "名前" タイプ= "XS:文字列" 使用= "オプション" /> <XS:属性名= "コメント" タイプ= "XS:文字列" 使用= "オプション"/> </ XS:拡張> </ XS:complexContentを> </ XS:complexTypeの> <XS:要素名=" ログイン」タイプ= "LogActionメソッド" のsubstitutionGroup = "アクション" />

<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の名前= "IncomingType"> <XS:complexContentを> <XS:拡張ベース= "TopLevelActionType" /> </ XS:complexContentを> </ XS:complexTypeの> <XS:要素名= "受信" タイプ=」 IncomingType」のsubstitutionGroup = "toplevelaction" /> <XS:complexTypeの名= "OutgoingType"> <XS:complexContentを> <XS:増設ベース= "TopLevelActionType" /> </ XS:complexContentを> </ XS:complexTypeの> <XS:要素名= "発信" タイプ= "OutgoingType" のsubstitutionGroup = "toplevelaction" /> <XS:complexTypeの名= "また、ProxyAction"> <XS:complexContentを> <XS:増設ベース= "ACTIONTYPE"> <XS:すべて> <XS :要素名= "忙しい" のminOccurs = "0"> <XS:complexTypeの> <XS:グループREF = "ノード" /> </ XS:complexTypeの> </ XS:要素> <XS:要素名= "noanswer" minOccurs = "0"> <XS:complexTypeの> <XS:グループREF = "ノード" /> </ XS:complexTypeの> </ XS:要素> <XS:要素名= "失敗" のminOccurs = "0"> < XS:complexTypeの> <XS:グループREF = "ノード" /> </ XS:complexTypeの> </ XS:要素> <XS:要素名= "リダイレクト" のminOccurs = "0"> <XS:complexTypeの> <XS:グループREF = "ノード" /> </ XS:complexTypeの> </ XS:要素> <XS:要素名= "デフォルト" のminOccurs = "0"> <XS:complexTypeの> <XS:グループREF = "ノード" /> </ XS:complexTypeの> </ XS:要素> </ XS:すべて> <XS:属性名= "タイムアウト" タイプ= "XS:POSITIVEINTEGER" 使用= "オプションの" デフォルト= "20" /> <XS:属性名= "再帰" タイプ= "YesNoType" 使用= "オプションの" デフォルト=」はい "/>

<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:属性名= "発注" タイプ= "OrderingType" 使用= "オプションの" デフォルト= "パラレル" /> </ XS:拡張> </ XS:complexContentを> </ XS:complexTypeの> <XS:要素名= "プロキシ" タイプ= "また、ProxyAction" のsubstitutionGroup = "アクション" /> <XS:complexTypeの名前は= "RedirectAction"> <XS:complexContentを> <XS:増設ベース= "ACTIONTYPE"> <XS:属性名= "永久" タイプ= "YesNoType" デフォルト= "なし" /> </ XS:拡張> </ XS:complexContentを> </ XS:complexTypeの> <XS:要素名= "リダイレクト" タイプ= "RedirectAction" のsubstitutionGroup = "アクション" /> <XS:complexTypeの名前= "RejectAction"> <XS:complexContentを> <XS:拡張ベース= "ACTIONTYPE"> <XS:属性名= "ステータス" タイプ= "StatusType" 使用= "必須" /> <XS:属性名前= "理由" タイプ= "XS:文字列" 使用= "オプション" /> </ XS:拡張> </ XS:complexContentを> </ XS:complexTypeの> <XS:要素名= "拒否" タイプ= "RejectAction "のsubstitutionGroup =" アクション "/> <XS:complexTypeの名=" MailAction "> <XS:complexContentを> <XS:拡張ベース=" ACTIONTYPE "> <XS:グループREF =" ノード "/> <XS:属性名= "URL" タイプ= "XS:anyURIの"拡張子> </ XS::complexContentを> </ XS:complexTypeの> <XS:要素名= "メール" タイプ= "MailAction" のsubstitutionGroup = "アクション" /> <XS:complexTypeの= "必要" /> </ XSを使用名前= "サブアクション"> <XS:属性名= "参照" タイプ= "XS:文字列":complexTypeの> <XS:complexTypeの名= "AncillaryType" /> <XS:complexTypeの使用は= /> </ XS "必要"名前= "SubactionType"> <XS:グループREF = "ノード" /> <XS:属性名= "ID" 使用= "必須" /> </ XS:complexTypeの> <XS:complexTypeの名は= "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:配列> <XS:要素名= "補助" タイプ= "AncillaryType" のminOccurs = "0" のmaxOccurs = "1" /> <XS:要素名= "サブアクション" タイプ= "SubactionType" のminOccurs = "0" maxOccurs = "無制限" /> <XS:要素REF = "toplevelaction" のminOccurs = "0" のmaxOccurs = "無制限"> <XS:注釈> <XS:ドキュメント>どれでもトップレベルのアクションが複数回現れてはならない</ XS。 :ドキュメント> </ XS:注釈> </ XS:要素> </ XS:配列> </ XS:complexTypeの> <XS:要素名= "CPL" タイプ= "CPLType" /> </ XS:スキーマ> 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]ローゼンバーグ、J.、Schulzrinneと、H.、カマリロ、G.、ジョンストン、A.、ピーターソン、J.、スパークス、R.、ハンドレー、M.、およびE.学生、 "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

[2]ブレイ、T.、パオリ、J.、Sperberg-マックイーン、CM、MALER、E.、およびF. Yergeau、 "拡張マークアップ言語(XML)1.0(第3版)"、W3C勧告REC-XML-20040204 、World Wide Webコンソーシアム(W3C)、の利用可能な2004年2月。

[3] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.

[3]ブラドナーのは、S.は、BCP 14、RFC 2119、1997年3月の "RFCsにおける使用のためのレベルを示すために"。

[4] Hinden, R. and S. Deering, "Internet Protocol Version 6 (IPv6) Addressing Architecture", RFC 3513, April 2003.

[4] HindenとR.とS.デアリング、 "インターネットプロトコルバージョン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

[5]デイビス、M. F.及びM. Duerst、 "Unicode正規化フォーム"、Unicode標準の附属書#15、ユニコードコンソーシアム、2003年4月改訂23。ユニコード4.0.0の一部。で利用可能。

[6] Davis, M. F., "Case Mappings", Unicode Standard Annex #21, Unicode Consortium, March 2001. Revision 5; part of Unicode 3.2.0. Available at

[6]デイビス、M. F.、 "ケースマッピング"、Unicode規格付属書#21、ユニコードコンソーシアム、2001年3月改訂5。ユニコード3.2.0の一部。で利用可能。

[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]ドーソン、F.とD. Stenerson、 "インターネットカレンダーおよびスケジューリング中核オブジェクト仕様(iCalendar形式)"、RFC 2445、1998年11月。

[9] Eggert, P., "Sources for Time Zone and Daylight Saving Time Data". Available at


[10] Mealling, M. and R. Daniel, "URI Resolution Services Necessary for URN Resolution", RFC 2483, January 1999.

[10] Mealling、M.とR.ダニエル、 "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

[11]ブレイ、T.、オランダ、D.、およびA.素人、 "XMLで名前空間"、W3C勧告REC-XML-名-19990114、World Wide Webコンソーシアム(W3C)、1999年1月には利用可能でhttp:/ /。

[12] Moats, R., "URN Syntax", RFC 2141, May 1997.

[12]堀、R.、 "URN構文"、RFC 2141、1997年5月。

[13] Moats, R., "A URN Namespace for IETF Documents", RFC 2648, August 1999.

[13]堀、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]村田、M.、St.Laurent、S.、およびD.コーン、 "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.


[17] Lennox, J. and H. Schulzrinne, "Call Processing Language Framework and Requirements", RFC 2824, May 2000.

[17]レノックス、J.とH. Schulzrinneと、 "コール処理言語フレームワークと要件"、RFC 2824、2000年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

[18] Raggett、D.、ル・オードブル、A.、およびI.ジェイコブス、 "HTML 4.01仕様書"、W3C勧告REC-html401-19991224、World Wide Webコンソーシアム(W3C)は、httpで1999年12月利用可能://。

[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)、標準化、ジュネーブ、スイス、12月の国際組織2000。

[21] DeRose, S., Maler, E., Orchard, D., and B. Trafford, "XML Linking Language (XLink) Version 1.0", W3C Recommendation REC-xlink-20010627, World Wide Web Consortium (W3C), June 2001. Available at

[21] DeRose、S.、MALER、E.、オーチャード、D.、およびB.トラフォード、 "XMLリンク言語(XLinkの)バージョン1.0"、W3C勧告REC-XLINK-20010627、World Wide Webコンソーシアム(W3C) 2001年6月利用可能。

[22] Showalter, T., "Sieve: A Mail Filtering Language", RFC 3028, January 2001.

[22]ショーウォルター監督、T.、 "ふるい:メールフィルタ言語"、RFC 3028、2001年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]国際電気通信連合、 - 、勧告Q.931、国際電気通信連合、ジュネーブ、スイス、1993年3月「デジタル加入者線信号システム第1号(DSS 1)基本呼制御のためのISDNユーザ・網インタフェースレイヤ3仕様」。

[24] Levin, O., "H.323 Uniform Resource Locator (URL) Scheme Registration", RFC 3508, April 2003.

[24]レヴィン、O.、 "H.323のURL(Uniform Resource Locator)スキームの登録"、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アムステルダムAvenue、MC 0401ニューヨークのジョナサン・レノックス部門、NY 10027 USA



Xiaotao Wu Dept. of Computer Science Columbia University 1214 Amsterdam Avenue, MC 0401 New York, NY 10027 USA

コンピュータサイエンスコロンビア大学1214アムステルダムAvenue、MC 0401ニューヨークのXiaotao呉部長、NY 10027 USA



Henning Schulzrinne Dept. of Computer Science Columbia University 1214 Amsterdam Avenue, MC 0401 New York, NY 10027 USA

コンピュータサイエンスコロンビア大学1214アムステルダムAvenue、MC 0401ニューヨークのヘニングSchulzrinneと部長、NY 10027 USA



Full Copyright Statement


Copyright (C) The Internet Society (2004).


This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.

この文書では、BCP 78に含まれる権利と許可と制限の適用を受けており、その中の記載を除いて、作者は彼らのすべての権利を保有します。


この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットソサエティおよびインターネット・エンジニアリング・タスク・フォース放棄すべての保証、明示または、(もしあれば)後援ISに設けられています。黙示、情報の利用は、特定の目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証含むがこれらに限定されません。

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


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は、その注意にこの標準を実装するために必要とされる技術をカバーすることができる任意の著作権、特許または特許出願、またはその他の所有権を持ってすべての利害関係者を招待します。 ietf-ipr@ietf.orgのIETFに情報を記述してください。



Funding for the RFC Editor function is currently provided by the Internet Society.

RFC Editor機能のための基金は現在、インターネット協会によって提供されます。