[要約] RFC 3880は、インターネット電話サービスのユーザー制御のための言語であるCPLについての要約です。このRFCの目的は、ユーザーがインターネット電話サービスを制御するための標準化された言語を提供することです。
Network Working Group J. Lennox
Request for Comments: 3880 X. Wu
Category: Standards Track H. Schulzrinne
Columbia University
October 2004
Call Processing Language (CPL): A Language for User Control of Internet Telephony Services
コール処理言語（CPL）：インターネットテレフォニーサービスのユーザー制御のための言語
Status of this Memo
本文書の位置付け
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態とステータスについては、「インターネット公式プロトコル標準」（STD 1）の現在のエディションを参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2004).
著作権（c）The Internet Society（2004）。
Abstract
概要
This document defines the Call Processing Language (CPL), a language to describe and control Internet telephony services. It is designed to be implementable on either network servers or user agents. It is meant to be simple, extensible, easily edited by graphical clients, and independent of operating system or signalling protocol. It is suitable for running on a server where users may not be allowed to execute arbitrary programs, as it has no variables, loops, or ability to run external programs.
このドキュメントでは、インターネットテレフォニーサービスを説明および制御する言語であるコール処理言語（CPL）を定義します。ネットワークサーバーまたはユーザーエージェントのいずれかで実装できるように設計されています。これは、シンプルで拡張可能で、グラフィカルなクライアントが簡単に編集し、オペレーティングシステムまたはシグナリングプロトコルから独立していることを意図しています。変数、ループ、または外部プログラムを実行する能力がないため、ユーザーが任意のプログラムを実行することを許可されないサーバーで実行するのに適しています。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Conventions of This Document. . . . . . . . . . . . . . 4
2. Structure of CPL Scripts . . . . . . . . . . . . . . . . . . . 4
2.1. High-level Structure. . . . . . . . . . . . . . . . . . 4
2.2. Abstract Structure of a Call Processing Action. . . . . 5
2.3. Location Model. . . . . . . . . . . . . . . . . . . . . 6
2.4. XML Structure . . . . . . . . . . . . . . . . . . . . . 6
3. Script Structure: Overview . . . . . . . . . . . . . . . . . . 7
4. Switches . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
4.1. Address Switches. . . . . . . . . . . . . . . . . . . . 9
4.1.1. Usage of "address-switch" with SIP. . . . . . . 11
4.2. String Switches . . . . . . . . . . . . . . . . . . . . 12
4.2.1. Usage of "string-switch" with SIP . . . . . . . 13
4.3. Language Switches . . . . . . . . . . . . . . . . . . . 14
4.3.1. Usage of "language-switch" with SIP . . . . . . 14
4.4. Time Switches . . . . . . . . . . . . . . . . . . . . . 15
4.4.1. iCalendar differences and implementation
issues. . . . . . . . . . . . . . . . . . . . . 20
4.5. Priority Switches . . . . . . . . . . . . . . . . . . . 21
4.5.1. Usage of "priority-switch" with SIP . . . . . . 22
5. Location Modifiers . . . . . . . . . . . . . . . . . . . . . . 22
5.1. Explicit Location . . . . . . . . . . . . . . . . . . . 23
5.1.1. Usage of "location" with SIP. . . . . . . . . . 23
5.2. Location Lookup . . . . . . . . . . . . . . . . . . . . 24
5.2.1. Usage of "lookup" with SIP. . . . . . . . . . . 25
5.3. Location Removal. . . . . . . . . . . . . . . . . . . . 25
5.3.1. Usage of "remove-location" with SIP . . . . . . 26
6. Signalling Operations. . . . . . . . . . . . . . . . . . . . . 26
6.1. Proxy . . . . . . . . . . . . . . . . . . . . . . . . . 26
6.1.1. Usage of "proxy" with SIP . . . . . . . . . . . 29
6.2. Redirect. . . . . . . . . . . . . . . . . . . . . . . . 29
6.2.1. Usage of "redirect" with SIP. . . . . . . . . . 30
6.3. Reject. . . . . . . . . . . . . . . . . . . . . . . . . 30
6.3.1. Usage of "reject" with SIP. . . . . . . . . . . 30
7. Non-signalling Operations. . . . . . . . . . . . . . . . . . . 31
7.1. Mail. . . . . . . . . . . . . . . . . . . . . . . . . . 31
7.1.1. Suggested Content of Mailed Information . . . . 32
7.2. Log . . . . . . . . . . . . . . . . . . . . . . . . . . 32
8. Subactions . . . . . . . . . . . . . . . . . . . . . . . . . . 33
9. Ancillary Information. . . . . . . . . . . . . . . . . . . . . 34
10. Default Behavior . . . . . . . . . . . . . . . . . . . . . . . 35
11. CPL Extensions . . . . . . . . . . . . . . . . . . . . . . . . 35
12. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
12.1. Example: Call Redirect Unconditional. . . . . . . . . . 37
12.2. Example: Call Forward Busy/No Answer. . . . . . . . . . 38
12.3. Example: Call Forward: Redirect and Default . . . . . . 39
12.4. Example: Call Screening . . . . . . . . . . . . . . . . 40
12.5. Example: Priority and Language Routing. . . . . . . . . 41
12.6. Example: Outgoing Call Screening. . . . . . . . . . . . 42
12.7. Example: Time-of-day Routing. . . . . . . . . . . . . . 43
12.8. Example: Location Filtering . . . . . . . . . . . . . . 44
12.9. Example: Non-signalling Operations. . . . . . . . . . . 45
12.10. Example: Hypothetical Extensions. . . . . . . . . . . . 46
12.11. Example: A Complex Example. . . . . . . . . . . . . . . 48
13. Security Considerations. . . . . . . . . . . . . . . . . . . . 49
14. IANA Considerations. . . . . . . . . . . . . . . . . . . . . . 49
14.1. URN Sub-Namespace Registration for
urn:ietf:params:xml:ns:cpl. . . . . . . . . . . . . . . 49
14.2. Schema registration . . . . . . . . . . . . . . . . . . 50
14.3. MIME Registration . . . . . . . . . . . . . . . . . . . 50
15. Acknowledgments. . . . . . . . . . . . . . . . . . . . . . . . 51
A. An Algorithm for Resolving Time Switches . . . . . . . . . . . 52
B. Suggested Usage of CPL with H.323. . . . . . . . . . . . . . . 53
B.1. Usage of "address-switch" with H.323. . . . . . . . . . 53
B.2. Usage of "string-switch" with H.323 . . . . . . . . . . 55
B.3. Usage of "language-switch" with H.323 . . . . . . . . . 55
B.4. Usage of "priority-switch" with H.323 . . . . . . . . . 55
B.5. Usage of "location" with H.323. . . . . . . . . . . . . 56
B.6. Usage of "lookup" with H.323. . . . . . . . . . . . . . 56
B.7. Usage of "remove-location" with H.323 . . . . . . . . . 56
C. The XML Schema for CPL . . . . . . . . . . . . . . . . . . . . 56
Normative References . . . . . . . . . . . . . . . . . . . . . . . 70
Informative References . . . . . . . . . . . . . . . . . . . . . . 71
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 73
Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 74
The Call Processing Language (CPL) is a language that can be used to describe and control Internet telephony services. It is not tied to any particular signalling architecture or protocol; it is anticipated that it will be used with both the Session Initiation Protocol (SIP) [1] and H.323 [16].
コール処理言語（CPL）は、インターネットテレフォニーサービスを説明および制御するために使用できる言語です。特定のシグナリングアーキテクチャまたはプロトコルに結び付けられていません。セッション開始プロトコル（SIP）[1]とH.323 [16]の両方で使用されると予想されます。
CPL is powerful enough to describe a large number of services and features, but it is limited in power so that it can run safely in Internet telephony servers. The intention is to make it impossible for users to do anything more complex (and dangerous) than describe Internet telephony services. The language is not Turing-complete, and provides no way to write loops or recursion.
CPLは多数のサービスと機能を説明するのに十分強力ですが、インターネットテレフォニーサーバーで安全に実行できるように、電力が制限されています。意図は、ユーザーがインターネットテレフォニーサービスを説明するよりも複雑な（そして危険な）ことを行うことを不可能にすることです。この言語は完全に完全に完全ではなく、ループや再帰を書き込む方法を提供しません。
CPL is also designed to be easily created and edited by graphical tools. It is based on the Extensible Markup Language (XML) [2], so parsing it is easy and many parsers for it are publicly available.
CPLは、グラフィカルツールによって簡単に作成および編集できるように設計されています。これは、拡張可能なマークアップ言語（XML）[2]に基づいているため、解析するのは簡単で、多くのパーサーが公開されています。
The structure of the language maps closely to its behavior, so an editor can understand any valid script, even ones written by hand. The language is also designed so that a server can easily confirm the validity of a script when the server receives it, rather than discovering problems while a call is being processed.
言語の構造は、その動作に密接にマッピングされるため、エディターは手で書かれたスクリプトであっても、有効なスクリプトを理解できます。言語は、サーバーがコールの処理中に問題を発見するのではなく、サーバーが受信したときにサーバーがスクリプトの有効性を簡単に確認できるように設計されています。
Implementations of CPL are expected to take place both in Internet telephony servers and in advanced clients; both can usefully process and direct users' calls. This document primarily addresses the usage in servers. A mechanism will be needed to transport scripts between clients and servers; this document does not describe such a mechanism, but related documents will.
CPLの実装は、インターネットテレフォニーサーバーと上級クライアントの両方で行われると予想されます。どちらもユーザーの通話を有用に処理および直接することができます。このドキュメントでは、主にサーバーの使用について説明します。クライアントとサーバー間でスクリプトを輸送するには、メカニズムが必要になります。このドキュメントでは、このようなメカニズムは説明されていませんが、関連するドキュメントは説明します。
The framework and requirements for the CPL architecture are described in RFC 2824, "Call Processing Language Framework and Requirements" [17].
CPLアーキテクチャのフレームワークと要件は、RFC 2824「コール処理言語フレームワークと要件」[17]で説明されています。
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.
このドキュメントでは、キーワードは「必要はない」、「必須」、「必要」、「shall」、「suff」、 "nove"、 "bulsed"、 "becommended"、 "、"、 "、" optional "BCP 14、RFC 2119 [3]に記載されているように解釈され、準拠したCPL実装の要件レベルを示します。
Some paragraphs are indented, like this; they give motivations of design choices, advice to implementors, or thoughts on future development of or extensions to CPL. They are not essential to the specification of the language, and are non-normative.
このように、いくつかの段落がインデントされています。彼らは、デザインの選択の動機、実装者へのアドバイス、またはCPLの将来の開発または拡張に関する考えを与えます。それらは言語の仕様に不可欠ではなく、非規範的です。
A CPL script consists of two types of information: ancillary information about the script, and call processing actions.
CPLスクリプトは、スクリプトに関する補助情報とコール処理アクションの2種類の情報で構成されています。
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.
補助情報は、サーバーがスクリプトを正しく処理するために必要な情報ですが、操作や決定を直接説明しない情報です。現在、補助情報は定義されていませんが、セクションは拡張機能で使用するために予約されています。
Abstractly, a call processing action is described by a collection of nodes that describe operations that can be performed or decisions that can be made. A node may have several parameters, which specify the precise behavior of the node; they usually also have outputs, which depend on the result of the decision or action.
抽象的には、コール処理アクションは、実行できる操作または決定できる決定を説明するノードのコレクションによって説明されます。ノードにはいくつかのパラメーターがあり、ノードの正確な動作を指定します。彼らは通常、決定または行動の結果に依存する出力も持っています。
For a graphical representation of a CPL action, see Figure 1. Nodes and outputs can be thought of informally as boxes and arrows; CPL is designed so that actions can be conveniently edited graphically using this representation. Nodes are arranged in a tree, starting at a single root node; outputs of nodes are connected to additional nodes. When an action is run, the action or decision described by the action's top-level node is performed; based on the result of that node, the server follows one of the node's outputs, and the subsequent node it points to is performed; this process continues until a node with no specified outputs is reached. Because the graph is acyclic, this will occur after a bounded and predictable number of nodes are visited.
CPLアクションのグラフィカルな表現については、図1を参照してください。ノードと出力は、非公式にボックスと矢印と考えることができます。CPLは、アクションをこの表現を使用してグラフィカルに便利に編集できるように設計されています。ノードは、単一のルートノードから始まるツリーに配置されます。ノードの出力は追加のノードに接続されています。アクションが実行されると、アクションのトップレベルノードによって説明されたアクションまたは決定が実行されます。そのノードの結果に基づいて、サーバーはノードの出力の1つに従い、それが指す後続のノードが実行されます。このプロセスは、指定された出力がないノードに到達するまで続きます。グラフは非環式であるため、これは境界と予測可能な数のノードにアクセスした後に発生します。
If an output to a node does not point to another node, it indicates that the CPL server should perform a node- or protocol-specific action. Some nodes have specific default behavior associated with them; for others, the default behavior is implicit in the underlying signalling protocol, or can be configured by the administrator of the server. For further details on this, see Section 10.
ノードへの出力が別のノードを指していない場合、CPLサーバーがノードまたはプロトコル固有のアクションを実行する必要があることを示します。一部のノードには、それらに関連付けられた特定のデフォルト動作があります。その他の場合、デフォルトの動作は、基礎となるシグナリングプロトコルで暗黙的であるか、サーバーの管理者によって構成されます。詳細については、セクション10を参照してください。
_________________ ___________________ ________ busy
| Address-switch | | location | | proxy |--------\
Call-->| field: origin | ->| url: sip:jones@ |->|timeout:| timeout|
| subfield: host | / | example.com | | 10s |--------|
|-----------------|/ |___________________| | | failure|
| subdomain-of: | |________|--------|
| example.com | |
|-----------------| ___________________________________________/
| otherwise | /........................................
| |\|. Voicemail .
|_________________| \. ____________________ .
->| location | __________ .
. | url: sip:jones@ | | redirect | .
. | voicemail. |->| | .
. | example.com | |__________| .
. |____________________| .
........................................
Figure 1: Sample CPL Action: Graphical Version
図1：サンプルCPLアクション：グラフィカルバージョン
For flexibility, one piece of information necessary for CPL is not given as node parameters: the set of locations to which a call is to be directed. Instead, this set of locations is stored as an implicit global variable throughout the execution of a processing action (and its subactions). This allows locations to be retrieved from external sources, filtered, and so forth, without requiring general language support for such operations (which could harm the simplicity and tractability of understanding the language). The specific operations which add, retrieve, or filter location sets are given in Section 5.
柔軟性のために、CPLに必要な1つの情報は、ノードパラメーターとして与えられません。呼び出しが指示される場所のセット。代わりに、この場所のセットは、処理アクション（およびそのサブ作用）の実行を通じて、暗黙のグローバル変数として保存されます。これにより、そのような操作に対する一般的な言語サポートを必要とせずに、外部ソース、フィルター処理などから場所を取得できます（言語を理解するための単純さと扱いやすさを害する可能性があります）。追加、取得、またはフィルターの位置セットを追加、取得、またはフィルタリングする特定の操作をセクション5に示します。
For the incoming top-level call processing action, the location set is initialized to the empty set. For the outgoing action, it is initialized to the destination address of the call.
着信トップレベルのコール処理アクションの場合、位置設定は空のセットに初期化されます。発信アクションのために、コールの宛先アドレスに初期化されます。
Syntactically, CPL scripts are represented by XML documents. XML is thoroughly specified by the XML specification [2], and implementors of this specification should be familiar with that document. However, as a brief overview, XML consists of a hierarchical structure of tags; each tag can have a number of attributes. It is visually and structurally very similar to HTML [18], as both languages are simplifications of the earlier and larger standard SGML [19].
構文的に、CPLスクリプトはXMLドキュメントで表されます。XMLはXML仕様[2]によって徹底的に指定されており、この仕様の実装者はそのドキュメントに精通している必要があります。ただし、簡単な概要として、XMLはタグの階層構造で構成されています。各タグには多くの属性があります。両方の言語が以前の標準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).
図1のCPLスクリプトのグラフィカルな表現に対応するXMLドキュメントについては、図2を参照してください。CPLのノードと出力の両方は、XMLタグで表されます。パラメーターはXMLタグ属性で表されます。通常、ノードタグには出力タグが含まれており、その逆（いくつかの例外を除き：セクション5.1、5.3、7.1、および7.2を参照）。
The connection between the output of a node and another node is represented by enclosing the tag representing the pointed-to node inside the tag for the outer node's output. Convergence (several outputs pointing to a single node) is represented by subactions, discussed further in Section 8.
ノードの出力と別のノードの間の接続は、外側ノードの出力のタグ内の尖ったノードを表すタグを囲むことによって表されます。収束（単一のノードを指すいくつかの出力）は、セクション8でさらに説明します。
The higher-level structure of a CPL script is represented by tags corresponding to each piece of ancillary information, subactions, and top-level actions, in order. This higher-level information is all enclosed in a special tag "cpl", the outermost tag of the XML document.
CPLスクリプトの高レベル構造は、補助情報、サブアクション、およびトップレベルのアクションの各部分に対応するタグで表されます。この高レベルの情報はすべて、XMLドキュメントの最も外側のタグである特別なタグ「CPL」に囲まれています。
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.
CPLの完全なXMLスキーマは、付録Cに記載されています。このドキュメントのメインセクションの残りの部分は、CPLのセマンティクスを説明し、その構文を非公式に示しています。正式な構文については、付録を参照してください。
As mentioned, a CPL script consists of ancillary information, subactions, and top-level actions. The full syntax of the "cpl" node is given in Figure 3.
前述のように、CPLスクリプトは、補助情報、サブアクション、およびトップレベルのアクションで構成されています。「CPL」ノードの完全な構文を図3に示します。
<?xml version="1.0" encoding="UTF-8"?>
<cpl xmlns="urn:ietf:params:xml:ns:cpl"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="urn:ietf:params:xml:ns:cpl cpl.xsd ">
<subaction id="voicemail">
<location url="sip:jones@voicemail.example.com">
<redirect />
</location>
</subaction>
<incoming>
<address-switch field="origin" subfield="host">
<address subdomain-of="example.com">
<location url="sip:jones@example.com">
<proxy timeout="10">
<busy> <sub ref="voicemail" /> </busy>
<noanswer> <sub ref="voicemail" /> </noanswer>
<failure> <sub ref="voicemail" /> </failure>
</proxy>
</location>
</address>
<otherwise>
<sub ref="voicemail" />
</otherwise>
</address-switch>
</incoming>
</cpl>
Figure 2: Sample CPL Script: XML Version
図2：サンプルCPLスクリプト：XMLバージョン
Tag: "cpl" Parameters: None Sub-tags: "ancillary" See Section 9 "subaction" See Section 8 "outgoing" Top-level actions to take on this user's outgoing calls "incoming" Top-level actions to take on this user's incoming calls
タグ：「CPL」パラメーター：なしサブタグ：「補助」セクション9「サブアクション」を参照してください。「セクション8」を参照してください。着信コール
Figure 3: Syntax of the top-level "cpl" tag
図3：トップレベルの「CPL」タグの構文
Call processing actions, both top-level actions and subactions, consist of a tree of nodes and outputs. Nodes and outputs are both described by XML tags. There are four categories of CPL nodes: switches, which represent choices a CPL script can make, location modifiers, which add or remove locations from the location set, signalling operations, which cause signalling events in the underlying protocol, and non-signalling operations, which trigger behavior which does not effect the underlying protocol.
トップレベルのアクションとサブアクションの両方のコール処理アクションは、ノードと出力のツリーで構成されています。ノードと出力はどちらもXMLタグで説明されています。CPLノードには4つのカテゴリがあります。CPLスクリプトが作成できる選択を表すスイッチ、ロケーションモディファイ因子、位置セットからロケーションを追加または削除する、基礎となるプロトコルのシグナリングイベントを引き起こすシグナリング操作、および非署名操作を引き起こします。基礎となるプロトコルに影響を与えない動作をトリガーします。
Switches represent choices a CPL script can make, based on either attributes of the original call request or items independent of the call.
スイッチは、元のコールリクエストのいずれかの属性または呼び出しに依存しないアイテムに基づいて、CPLスクリプトが作成できる選択を表します。
All switches are arranged as a list of conditions that can match a variable. Each condition corresponds to a node output; the output points to the next node that should be executed if the condition is true. The conditions are tried in the order they are presented in the script; the output corresponding to the first node to match is taken.
すべてのスイッチは、変数に一致する条件のリストとして配置されます。各条件はノード出力に対応します。出力は、条件が真である場合に実行する必要がある次のノードを指します。条件は、スクリプトに表示される順序で試されます。一致する最初のノードに対応する出力が取得されます。
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.
すべてのスイッチタイプに適用される2つの特別なスイッチ出力があります。出力のリストのどこにでも発生する可能性のある出力「Not-Present」は、スイッチが一致する変数が元のコールセットアップリクエストに存在しなかった場合に真です。（このドキュメントでは、これは、情報が「不在」であると言うことによって時々説明されます。）それ以外の場合は出力が存在する場合に指定された最後の出力でなければなりませんが、他の条件が一致しない場合は一致します。
If no condition matches and no "otherwise" output was present in the script, the default script behavior is taken. See Section 10 for more information on this.
条件が一致せず、スクリプトに「それ以外の」出力が存在しなかった場合、デフォルトのスクリプト動作が実行されます。これの詳細については、セクション10を参照してください。
Switches MAY contain no outputs. They MAY only contain an "otherwise" output.
スイッチには出力が含まれていない場合があります。「それ以外の」出力のみが含まれる場合があります。
Such switches are not particularly useful, but might be created by tools which automatically generate CPL scripts.
このようなスイッチは特に役立ちませんが、CPLスクリプトを自動的に生成するツールによって作成される場合があります。
Address switches allow a CPL script to make decisions based on one of the addresses present in the original call request. They are summarized in Figure 4.
アドレススイッチにより、CPLスクリプトは、元のコールリクエストに存在するアドレスのいずれかに基づいて決定を下すことができます。それらを図4にまとめます。
Node: "address-switch" Outputs: "address" Specific addresses to match Parameters: "field" "origin", "destination", or "original-destination" "subfield" "address-type", "user", "host", "port", "tel", or "display" (also: "password" and "alias-type")
ノード：「アドレススイッチ」出力：「アドレス」特定のアドレスパラメーターを一致させる：「フィールド」「オリジン」、「宛先」、または「オリジナル廃止」「サブフィールド」「アドレスタイプ」、「ユーザー」、「ホスト」"、"ポート "、" tel "、または" display "（また：「パスワード」と「エイリアスタイプ」）
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
図4：「アドレススイッチ」ノードの構文
Address switches have two node parameters: "field" and "subfield". The mandatory "field" parameter allows the script to specify which address is to be considered for the switch: either the call's origin address (field "origin"), its current destination address (field "destination"), or its original destination (field "original-destination"), the destination the call had before any earlier forwarding was invoked. Servers MAY define additional field values.
アドレススイッチには、「フィールド」と「サブフィールド」の2つのノードパラメーターがあります。必須の「フィールド」パラメーターを使用すると、スクリプトは、スイッチに考慮されるアドレスを指定できます。コールのオリジンアドレス（フィールド "Origin"）、現在の宛先アドレス（フィールド "宛先"）、または元の宛先（フィールドのいずれか）「Original-destination」）、早期の転送が呼び出される前に電話がかかった宛先。サーバーは、追加のフィールド値を定義する場合があります。
The optional "subfield" specifies which part of the address is to be considered. The possible subfield values are: "address-type", "user", "host", "port", "tel", and "display". Additional subfield values MAY be defined for protocol-specific values. (The subfield "password" is defined for SIP in Section 4.1.1; the subfield "alias-type" is defined for H.323 in Appendix B.1.) If no subfield is specified, the "entire" address is matched; the precise meaning of this is defined for each underlying signalling protocol. Servers MAY define additional subfield values.
オプションの「サブフィールド」は、アドレスのどの部分を考慮するかを指定します。可能なサブフィールド値は、「アドレスタイプ」、「ユーザー」、「ホスト」、「ポート」、「Tel」、および「ディスプレイ」です。プロトコル固有の値に対して、追加のサブフィールド値を定義できます。（サブフィールド「パスワード」は、セクション4.1.1のSIPに対して定義されます。サブフィールド「エイリアスタイプ」は付録B.1のH.323に対して定義されます。）サブフィールドが指定されていない場合、「」アドレス全体が一致します。これの正確な意味は、基礎となる信号プロトコルごとに定義されます。サーバーは、追加のサブフィールド値を定義できます。
The subfields are defined as follows:
サブフィールドは次のように定義されています。
address-type: This indicates the type of the underlying address, i.e., the URI scheme, if the address can be represented by a URI. The types specifically discussed by this document are "sip", "tel", and "h323". The address type is not case-sensitive. It has a value for all defined address types.
アドレスタイプ：これは、アドレスをURIで表現できる場合、基礎となるアドレスのタイプ、つまりURIスキームを示します。このドキュメントで具体的に説明されているタイプは、「SIP」、「Tel」、および「H323」です。アドレスタイプは症例に敏感ではありません。定義されたすべてのアドレスタイプに値があります。
user: This subfield of the address indicates, for e-mail style addresses, the user part of the address. For a telephone number style address, it includes the subscriber number. This subfield is case-sensitive; it may be absent.
ユーザー：アドレスのこのサブフィールドは、電子メールスタイルアドレスのアドレスのユーザー部分を示しています。電話番号スタイルのアドレスには、サブスクライバー番号が含まれています。このサブフィールドはケースに敏感です。欠席している可能性があります。
host: This subfield of the address indicates the Internet host name or IP address corresponding to the address, in host name, IPv4, or IPv6 [4] textual representation format. Host names are compared as strings. IP addresses are compared numerically. (In particular, the presence or location of an IPv6 :: omitted-zero-bits block is not significant for matching purposes.) Host names are never equal to IP addresses -- no DNS resolution is performed. IPv4 addresses are never equal to IPv6 addresses, even if the IPv6 address is a v4-in-v6 embedding. This subfield is not case sensitive, and may be absent.
ホスト：アドレスのこのサブフィールドは、ホスト名、IPv4、またはIPv6 [4]テキスト表現形式で、アドレスに対応するインターネットホスト名またはIPアドレスを示します。ホスト名は文字列として比較されます。IPアドレスは数値的に比較されます。（特に、IPv6 ::省略ゼロビットブロックの存在または位置は、一致する目的では重要ではありません。）ホスト名はIPアドレスとは決して等しくありません。DNS解像度は実行されません。IPv6アドレスがV4-in-V6埋め込みであっても、IPv4アドレスは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.
ポート：このサブフィールドは、数値形式で数値的にアドレスのTCPまたはUDPポート番号を示します。小数桁のみを含む必要があるため、症例に敏感ではありません。主要なゼロは無視されます。
tel: This subfield indicates a telephone subscriber number, if the address contains such a number. It is not case sensitive (telephone numbers may contain the symbols 'A', 'B', 'C', or 'D'), and may be absent. It may be matched using the "subdomain-of" match operator. Punctuation and separator characters in telephone numbers are discarded.
Tel：このサブフィールドは、アドレスにそのような番号が含まれている場合、電話サブスクライバー番号を示します。それはケースに敏感ではありません（電話番号にはシンボル「A」、「B」、「C」、または「D」が含まれる場合があります）。「サブドメイン」マッチオペレーターを使用して一致する場合があります。電話番号の句読点とセパレーターの文字は破棄されます。
display: This subfield indicates a "display name" or user-visible name corresponding to an address. It is a Unicode string, and is matched using the case-insensitive algorithm described in Section 4.2. The "contains" operator may be applied to it. It may be absent.
表示：このサブフィールドは、アドレスに対応する「ディスプレイ名」またはユーザー可視名を示します。これはユニコード文字列であり、セクション4.2で説明されているケース非感受性アルゴリズムを使用して一致します。「Contains」オペレーターが適用される場合があります。欠席している可能性があります。
For any completely unknown subfield, the server MAY reject the script at the time it is submitted with an indication of the problem; if a script with an unknown subfield is executed, the server MUST consider the "not-present" output to be the valid one.
完全に未知のサブフィールドの場合、サーバーは、問題の兆候が提出された時点でスクリプトを拒否する場合があります。未知のサブフィールドを持つスクリプトが実行された場合、サーバーは「存在しない」出力を有効な出力と見なす必要があります。
The "address" output tag may take exactly one of three possible parameters, indicating the kind of matching allowed.
「アドレス」出力タグは、可能な3つのパラメーターの1つを正確に取得する場合があり、許可された一致の種類を示します。
is: An output with this match operator is followed if the subfield being matched in the "address-switch" exactly matches the argument of the operator. It may be used for any subfield, or for the entire address if no subfield was specified.
IS：「アドレススイッチ」で一致しているサブフィールドがオペレーターの引数と正確に一致する場合、このマッチオペレーターの出力が続きます。任意のサブフィールドに、またはサブフィールドが指定されていない場合はアドレス全体に使用できます。
subdomain-of: This match operator applies only for the subfields "host" and "tel". In the former case, it matches if the hostname being matched is a subdomain of the domain given in the argument of the match operator; thus, subdomain-of="example.com" would match the hostnames "example.com", "research.example.com", and "zaphod.sales.internal.example.com". IP addresses may be given as arguments to this operator; however, they only match exactly. In the case of the "tel" subfield, the output matches if the telephone number being matched has a prefix that matches the argument of the match operator; subdomain-of="1212555" would match the telephone number "1 212 555 1212."
サブドメイン：このマッチオペレーターは、サブフィールド「ホスト」と「Tel」にのみ適用されます。前者の場合、一致するホスト名が一致オペレーターの引数に与えられたドメインのサブドメインであるかどうかは一致します。したがって、subdomain-of = "Example.com"は、HostNames "Example.com"、 "Research.example.com"、および「zaphod.sales.internal.example.com」と一致します。IPアドレスは、このオペレーターの引数として与えられる場合があります。ただし、それらは正確にのみ一致します。「Tel」サブフィールドの場合、一致する電話番号に出力が一致する場合に一致します。subdomain-of = "1212555"は電話番号 "1 212 555 1212に一致します。
contains: This match operator applies only for the subfield "display". The output matches if the display name being matched contains the argument of the match as a substring.
含有：このマッチオペレーターは、サブフィールド「ディスプレイ」にのみ適用されます。一致しているディスプレイ名が一致する場合、出力は一致します。
For SIP, the "origin" address corresponds to the address in the "From" header, "destination" corresponds to the "Request-URI", and "original-destination" corresponds to the "To" header.
SIPの場合、「Origin」アドレスは「From "Header」のアドレスに対応し、宛先」は「リクエスト-URI」に対応し、「オリジナルデステーション」は「ヘッダー」に対応します。
The "display" subfield of an address is the display-name part of the address, if it is present. Because of SIP's syntax, the "destination" address field will never have a "display" subfield.
アドレスの「ディスプレイ」サブフィールドは、アドレスが存在する場合のディスプレイ名部分です。SIPの構文のため、「宛先」アドレスフィールドには「ディスプレイ」サブフィールドがありません。
The "address-type" subfield of an address is the URI scheme of that address. Other address fields depend on that "address-type".
アドレスの「アドレスタイプ」サブフィールドは、そのアドレスのURIスキームです。他のアドレスフィールドは、その「アドレスタイプ」に依存します。
For SIP URIs, the "user", "host", and "port" subfields correspond to the "user," "host," and "port" elements of the URI syntax. (Note that, following the definitions of RFC 3261 [1], a SIP URI which does not specify a port is not the same as an explicit port 5060; the former is indicated by an absent port subfield.) The "tel" subfield is defined to be the "user" part of the URI, with visual separators stripped, if the "user=phone" parameter is given to the URI, or if the server is otherwise configured to recognize the user part as a telephone number. An additional subfield, "password", is defined to correspond to the "password" element of the SIP URI, and is case-sensitive. However, use of this field is NOT RECOMMENDED for general security reasons.
SIP URIの場合、「ユーザー」、「ホスト」、および「ポート」サブフィールドは、URI構文の「ユーザー」、「ホスト」、「ポート」要素に対応しています。（RFC 3261 [1]の定義に従って、ポートを指定しないSIP URIは明示的なポート5060と同じではありません。前者は、ポートサブフィールドがないことを示しています。）「Tel」サブフィールドは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.
H323 URLの場合、サブフィールドは、付録Bで説明されているスキームに従って設定できます。
For other URI schemes, only the "address-type" subfield is defined by this specification; servers MAY set other pre-defined subfields, or MAY support additional subfields.
他のURIスキームの場合、「アドレスタイプ」サブフィールドのみがこの仕様で定義されます。サーバーは、他の定義されたサブフィールドを設定するか、追加のサブフィールドをサポートする場合があります。
If no subfield is specified for addresses in SIP messages, the string matched is the URI part of the address. For "is" matches, standard SIP URI matching rules are used; for "contains" matches, the URI is used verbatim.
SIPメッセージのアドレスにサブフィールドが指定されていない場合、一致する文字列はアドレスのURI部分です。「IS」マッチの場合、標準のSIP URIマッチングルールが使用されます。「Contains」マッチの場合、URIは逐語的に使用されます。
String switches allow a CPL script to make decisions based on free-form strings present in a call request. They are summarized in Figure 5.
文字列スイッチにより、CPLスクリプトは、コールリクエストに存在するフリーフォーム文字列に基づいて決定を下すことができます。それらを図5にまとめます。
Node: "string-switch" Outputs: "string" Specific string to match Parameters: "field" "subject", "organization", "user-agent", or "display"
ノード： "string-switch" outputs： "string"パラメーターを一致させる特定の文字列： "field" "subject"、 "organization"、 "user-agent"、または "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.
図5：「文字列スイッチ」ノード文字列スイッチの構文には、1つのノードパラメーター「フィールド」があります。必須の「フィールド」パラメーターは、一致する文字列を指定します。
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.
4つのフィールドが定義され、以下にリストされています。これらの各フィールドの値は、他の構造が定義されていないフリーフォームユニコード文字列です。
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 Standard Annex＃15 [5]で指定されているように、「互換性構成」（KC）形式に正規化されます。次に、Unicode Standard Annex＃21 [6]で指定されているように、文字列はロケールに依存しないカスレスマッピングを使用して比較されます。
Code to perform the first step, in Java and Perl, is available; see the links from Annex 5 of UAX 15 [5]. The case-insensitive string comparison in the Java standard class libraries already performs the second step; other Unicode-aware libraries should be similar.
JavaとPerlで最初のステップを実行するコードが利用可能です。UAX 15 [5]の付録5のリンクを参照してください。Java Standard Classライブラリにおけるケースに依存しない文字列比較は、すでに2番目のステップを実行しています。他のUnicode-Awareライブラリは似ているはずです。
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.
文字列マッチングの出力タグは「文字列」と呼ばれ、「IS」または「Contains」の1つである必須の引数があり、それぞれストリングの一致またはサブストリングの一致を示しています。
For SIP, the fields "subject", "organization", and "user-agent" correspond to the SIP header fields with the same name. These are used verbatim as they appear in the message.
SIPの場合、フィールド「サブジェクト」、「組織」、および「ユーザーエージェント」は、同じ名前のSIPヘッダーフィールドに対応しています。これらはメッセージに表示されるときに逐語的に使用されます。
The field "display" is not used, and is never present.
フィールド「ディスプレイ」は使用されておらず、決して存在しません。
Language switches allow a CPL script to make decisions based on the languages in which the originator of the call wishes to communicate. They are summarized in Figure 6.
言語スイッチにより、CPLスクリプトは、コールの発信者が通信を望んでいる言語に基づいて決定を下すことができます。それらを図6にまとめます。
Node: "language-switch" Outputs: "language" Specific string to match Parameters: None
ノード：「言語スイッチ」出力：「言語 "パラメーターに一致する特定の文字列：なし
Output: "language" Parameters: "matches" Match if the given language matches a language-range of the call.
出力：「言語」パラメーター：「指定された言語が通話の言語範囲に一致する場合、「一致」一致します。
Figure 6: Syntax of the "language-switch" node
図6：「言語スイッチ」ノードの構文
Language switches take no parameters.
言語スイッチはパラメーターを取りません。
The "language" output takes one parameter, "matches". The value of the parameter is a language-tag, as defined in RFC 3066 [7]. The caller may have specified a set of language-ranges, also as defined in RFC 3066. The CPL server checks each language-tag specified by the script against the language-ranges specified in the request.
「言語」出力は、1つのパラメーター「一致」を取ります。パラメーターの値は、RFC 3066 [7]で定義されている言語タグです。発信者は、RFC 3066で定義されているように、一連の言語範囲を指定した場合があります。CPLサーバーは、リクエストで指定された言語範囲に対してスクリプトで指定された各言語タグをチェックします。
See RFC 3066 for the details of how language-ranges match language-tags. Briefly, a language-range matches a language-tag if it exactly equals the tag, or if it exactly equals a prefix of the tag such that the first character following the prefix is "-".
言語範囲の言語タグと一致する方法の詳細については、RFC 3066を参照してください。簡単に言えば、言語範囲は、タグに正確に等しい場合、またはタグのプレフィックスに正確に等しい場合、言語タグと一致します。
If the caller specified the special language-range "*", it is ignored for the purpose of matching. Languages with a "q" value of 0 are also ignored.
発信者が特別な言語範囲「*」を指定した場合、一致する目的で無視されます。「Q」値が0の言語も無視されます。
This switch MAY be not-present.
このスイッチは存在しない場合があります。
The language-ranges for the "language-switch" switch are obtained from the SIP "Accept-Language" header field. The switch is not-present if the initial SIP request did not contain this header field.
「Language-Switch」スイッチの言語範囲は、SIP「Accect-Language」ヘッダーフィールドから取得されます。最初のSIPリクエストにこのヘッダーフィールドが含まれていない場合、スイッチは存在しません。
Note that because of CPL's first-match semantics in switches, "q" values other than 0 of the "Accept-Language" header fields are ignored.
スイッチでのCPLの最初の試合セマンティクスのため、「Q」値は「Accept-Language」ヘッダーフィールドの0以外の値を無視していることに注意してください。
Time switches allow a CPL script to make decisions based on the time and/or date the script is being executed. They are summarized in Figure 7.
タイムスイッチにより、CPLスクリプトは、スクリプトが実行されている時間および/または日付に基づいて決定を下します。それらを図7にまとめます。
Time switches are independent of the underlying signalling protocol.
時間スイッチは、基礎となるシグナル伝達プロトコルとは無関係です。
Node: "time-switch" Outputs: "time" Specific time to match Parameters: "tzid" RFC 2445 Time Zone Identifier "tzurl" RFC 2445 Time Zone URL
ノード： "Time-Switch"出力：「時間 "パラメーターを一致させる特定の時間：" Tzid "RFC 2445タイムゾーン識別子" TZURL "RFC 2445タイムゾーンURL
Output: "time" Parameters: "dtstart" Start of interval (RFC 2445 DATE-TIME) "dtend" End of interval (RFC 2445 DATE-TIME) "duration" Length of interval (RFC 2445 DURATION) "freq" Frequency of recurrence ("secondly", "minutely", "hourly", "daily", "weekly", "monthly", or "yearly") "interval" How often the recurrence repeats "until" Bound of recurrence (RFC 2445 DATE-TIME) "count" Number of occurrences of recurrence "bysecond" List of seconds within a minute "byminute" List of minutes within an hour "byhour" List of hours of the day "byday" List of days of the week "bymonthday" List of days of the month "byyearday" List of days of the year "byweekno" List of weeks of the year "bymonth" List of months of the year "wkst" First day of the work week "bysetpos" List of values within set of events specified
出力：「時間」パラメーター：「DTSTART」間隔の開始（RFC 2445日付）「DTEND」インターバルの終わり（RFC 2445日付）「期間」間隔の長さ（RFC 2445期間）（「2番目」、「微小」、「1時間ごと」、「毎日」、「毎週」、「毎年」、または「年間」） "間隔"再発の境界まで再発が繰り返される頻度）「カウント」再発の発生数「秒」の「秒」リスト1分以内の秒単位の「秒」リスト1時間以内の議事録「1日の時間」の「時間」の「1日の時間」リスト「Byday "by of of the monthday」リストのリストのリスト月の日「by yearday "of the Year" byweekno "byweekno" by bymonth "bymonth" of of the year "wkst" wkst "bysetpos" bysetpos "bysetpos" bysetpos fist in of events内のリストのリスト指定された
Figure 7: Syntax of the "time-switch" node
図7：「タイムスイッチ」ノードの構文
Time switches are based closely on the specification of recurring intervals of time in the Internet Calendaring and Scheduling Core Object Specification (iCalendar COS), RFC 2445 [8].
時間スイッチは、インターネットカレンダーの定期的な時間間隔の仕様に密接に基づいており、コアオブジェクト仕様（ICALENDAR COS）、RFC 2445 [8]。
This allows CPL scripts to be generated automatically from calendar books. It also allows us to re-use the extensive existing work specifying time intervals.
これにより、CPLスクリプトをカレンダー帳から自動的に生成できます。また、時間間隔を指定する広範な既存の作業を再利用することもできます。
If future standards-track documents are published that update or obsolete RFC 2445, any changes or clarifications those documents make to recurrence handling apply to CPL time-switches as well.
RFC 2445を更新または廃止する将来の標準トラックドキュメントが公開されている場合、これらのドキュメントが再発処理に加えて、CPLの時刻回転にも適用されるように変更されます。
An algorithm to determine whether an instant falls within a given recurrence is given in Appendix A.
インスタントが特定の再発内に収まるかどうかを判断するためのアルゴリズムは、付録Aに示されています。
The "time-switch" tag takes two optional parameters, "tzid" and "tzurl", both of which are defined in RFC 2445 (Sections 4.8.3.1 and 4.8.3.5 respectively). The "tzid" is the identifying label by which a time zone definition is referenced. If it begins with a forward slash (solidus), it references a to-be-defined global time zone registry; otherwise it is locally-defined at the server. The "tzurl" gives a network location from which an up-to-date VTIMEZONE definition for the timezone can be retrieved.
「タイムスイッチ」タグは、「Tzid」と「Tzurl」の2つのオプションパラメーターを取ります。どちらもRFC 2445で定義されています（それぞれセクション4.8.3.1と4.8.3.5）。「Tzid」は、タイムゾーンの定義が参照される識別ラベルです。それが前方スラッシュ（Solidus）から始まる場合、それは定義されたグローバルタイムゾーンレジストリを参照します。それ以外の場合は、サーバーでローカルに定義されています。「Tzurl」は、タイムゾーンの最新のvtimezone定義を取得できるネットワークの場所を提供します。
While "tzid" labels that do not begin with a forward slash are locally defined, it is RECOMMENDED that servers support at least the naming scheme used by the Olson Time Zone database [9]. Examples of timezone databases that use the Olson scheme are the zoneinfo files on most Unix-like systems, and the standard Java TimeZone class.
フォワードスラッシュから始まらない「Tzid」ラベルはローカルで定義されていますが、Serversは少なくともOlson Time Zoneデータベース[9]で使用される命名スキームをサポートすることをお勧めします。OLSONスキームを使用するTimeZoneデータベースの例は、ほとんどの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.
1年の間に昼間の節約時間の変更があるため、特定のタイムゾーンで時間スイッチを指定する必要があります。UTCのオフセットは十分ではありません。または、米国東部で午前9時から午後5時の間に開催された時刻のルーティングルールは、10月末に午前8時から午後4時まで開催され始めます。
Authors of CPL servers should be careful to handle correctly the intervals when local time is discontinuous, at the beginning or end of daylight-savings time. Note especially that some times may occur more than once when clocks are set back. The algorithm in Appendix A is believed to handle this correctly.
CPLサーバーの著者は、現地時間が不連続である場合、日光の節約時間の開始時または終了時に間隔を正しく処理するように注意する必要があります。特に、時計が後退したときに数回発生する場合があることに注意してください。付録Aのアルゴリズムは、これを正しく処理すると考えられています。
Time nodes specify a list of periods during which their output should be taken. They have two required parameters: "dtstart", which specifies the beginning of the first period of the list, and exactly one of "dtend" or "duration", which specify the ending time or the 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」という2つの必要なパラメーターと、それぞれ期間の終了時間または期間を指定する「DTEND」または「持続時間」の1つを正確に指定します。RFC 2445 [8]のセクション4.3.5で指定されているように、「DTSTART」および「DTEND」パラメーターは、ICALENDAR COS日付時間値としてフォーマットされます。タイムゾーンはトップレベルの「タイムスイッチ」タグで指定されているため、1つまたは2（フローティングまたはUTC時間）のみを使用できます。「持続時間」パラメーターは、RFC 2444のセクション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.
他のパラメーターが指定されていない場合、時間ノードは1回の期間のみを示します。より複雑な期間間隔のセットが再発として構築されます。再発は、再発ルールのタイプを示す「freq」パラメーターを含めることによって指定されます。「dtstart」、「dtend」、および「duration」以外のパラメーターは、「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」パラメーターは、次の値のいずれかを取得します。「2番目に」、秒以上の間隔に基づいて繰り返し期間を指定し、1分以上の間隔に基づいて繰り返し期間を指定します。「、1時間以上の間隔「毎日」に基づいて繰り返し期間を指定し、1日以上「毎週」の間隔に基づいて繰り返し期間を指定し、1週間または1週間または1週間またはそれに基づいて繰り返し期間を指定することを指定するために詳細、「毎月」、1か月以上の間隔に基づいて繰り返し期間を指定し、「年」を指定し、1年以上の間隔に基づいて繰り返し期間を指定します。これらの値は症例に敏感ではありません。
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」です。「2番目に」ルールの1秒ごと、「1時間ごとの」ルールでは「1時間ごとの」ルールの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.
"ut"パラメーターは、再発ルールを包括的に境界線にする日付または日付の値を定義します。「ut」で指定された値が指定された再発と同期されている場合、この日付または日付は再発の最後のインスタンスになります。日付時間として指定されている場合は、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.
「count」パラメーターは、再発を範囲に範囲するための発生数を定義します。「dtstart」パラメーターは、最初の発生としてカウントされます。「ut」および「count」パラメーターは、同じ「時間」出力で発生してはなりません。
The "bysecond" parameter specifies a comma-separated list of seconds within a minute. Valid values are 0 to 59. The "byminute" parameter specifies a comma-separated list of minutes within an hour. Valid values are 0 to 59. The "byhour" parameter specifies a comma-separated list of hours of the day. Valid values are 0 to 23.
「bysecond」パラメーターは、1分以内に秒数のコンマ分離リストを指定します。有効な値は0〜59です。「byminute」パラメーターは、1時間以内に数分のコンマ区切りリストを指定します。有効な値は0〜59です。「byhour」パラメーターは、1日の時間のコンマ分離されたリストを指定します。有効な値は0〜23です。
The "byday" parameter specifies a comma-separated list of days of the week. "MO" indicates Monday, "TU" indicates Tuesday, "WE" indicates Wednesday, "TH" indicates Thursday, "FR" indicates Friday, "SA" indicates Saturday, and "SU" indicates Sunday. These values are not case-sensitive.
「副次的」パラメーターは、曜日のコンマ分離されたリストを指定します。「Mo」は月曜日を示し、「Tu」は火曜日を示し、「We」は「水曜日」を示し、「Th」は木曜日「FR」を示し、金曜日「SA」は土曜日を示し、「SU」は日曜日を示します。これらの値は症例に敏感ではありません。
Each "byday" value can also be preceded by a positive (+n) or negative (-n) integer. If present, this indicates the nth occurrence of the specific day within the "monthly" or "yearly" recurrence. For example, within a "monthly" rule, +1MO (or simply 1MO) represents the first Monday within the month, whereas -1MO represents the last Monday of the month. If an integer modifier is not present, it means all days of this type within the specified frequency. For example, within a "monthly" rule, MO represents all Mondays within the month.
それぞれの「副次的」値の前には、正（n）または負（-n）整数が付いています。存在する場合、これは「毎月」または「年間」の再発内の特定の日のnが発生することを示します。たとえば、「毎月」ルール内では、1mo（または単に1mo）が月の最初の月曜日を表しますが、-1moは月の最後の月曜日を表します。整数修飾子が存在しない場合、指定された周波数内のこのタイプのすべての日を意味します。たとえば、「毎月」ルール内で、MOは月のすべての月曜日を表します。
The "bymonthday" parameter specifies a comma-separated list of days of the month. Valid values are 1 to 31 or -31 to -1. For example, -10 represents the tenth to the last day of the month.
「bymonthday」パラメーターは、月の日のコンマ分離されたリストを指定します。有効な値は1〜31または-31〜 -1です。たとえば、-10はその月の最終日から10番目を表します。
The "byyearday" parameter specifies a comma-separated list of days of the year. Valid values are 1 to 366 or -366 to -1. For example, -1 represents the last day of the year (December 31st) and -306 represents the 306th to the last day of the year (March 1st).
「byyearday」パラメーターは、今年の日のコンマ分離されたリストを指定します。有効な値は1〜366または-366〜 -1です。たとえば、-1は年の最終日（12月31日）を表し、-306は306日から最終日（3月1日）を表します。
The "byweekno" parameter specifies a comma-separated list of ordinals specifying weeks of the year. Valid values are 1 to 53 or -53 to -1. This corresponds to weeks according to week numbering as defined in ISO 8601 [20]. A week is defined as a seven day period, starting on the day of the week defined to be the week start (see "wkst"). Week number one of the calendar year is the first week which contains at least four (4) days in that calendar year. This parameter is only valid for "yearly" rules. For example, 3 represents the third week of the year.
「byweekno」パラメーターは、年の週を指定する序数のコンマ分離されたリストを指定します。有効な値は1〜53または-53〜 -1です。これは、ISO 8601 [20]で定義されている週番号に従って週に対応します。週は7日間の期間として定義され、週の開始と定義された週から始まります（「wkst」を参照）。暦年の週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.
注：月曜日の週の開始を仮定すると、53週目は1月1日が木曜日の場合にのみ発生します。
The "bymonth" parameter specifies a comma-separated list of months of the year. Valid values are 1 to 12.
「bymonth」パラメーターは、年間の月のコンマ分離されたリストを指定します。有効な値は1〜12です。
The "wkst" parameter specifies the day on which the work week starts. Valid values are "MO", "TU", "WE", "TH", "FR", "SA" and "SU". This is significant when a "weekly" recurrence has an interval greater than 1, and a "byday" parameter is specified. This is also significant in a "yearly" recurrence when a "byweekno" parameter is specified. The default value is "MO", following ISO 8601 [20].
「WKST」パラメーターは、勤務週間が始まる日を指定します。有効な値は、「MO」、「TU」、「WE」、「TH」、「FR」、「SA」、「SU」です。これは、「毎週」の再発が1より大きい間隔を持ち、「傍」パラメーターが指定されている場合に重要です。これは、「byweekno」パラメーターが指定されている場合の「毎年」再発でも重要です。デフォルト値は、ISO 8601 [20]に続く「MO」です。
The "bysetpos" parameter specifies a comma-separated list of values which corresponds to the nth occurrence within the set of events specified by the rule. Valid values are 1 to 366 or -366 to -1. It MUST only be used in conjunction with another byxxx parameter. For example, "the last work day of the month" could be represented as:
「bysetpos」パラメーターは、ルールで指定されたイベントのセット内のn番目の発生に対応する値のコンマ分離されたリストを指定します。有効な値は1〜366または-366〜 -1です。別のBYXXXパラメーターと組み合わせてのみ使用する必要があります。たとえば、「月の最後の仕事」は次のように表現できます。
<time -timerange- freq="monthly" byday="MO,TU,WE,TH,FR"
bysetpos="-1">
Each "bysetpos" value can include a positive (+n) or negative (-n) integer. If present, this indicates the nth occurrence of the specific occurrence within the set of events specified by the rule.
各「bysetpos」値には、正（n）または負（-n）整数を含めることができます。存在する場合、これはルールによって指定されたイベントのセット内での特定の発生のnが発生することを示します。
If byxxx parameter values are found which are beyond the available scope (i.e., bymonthday="30" in February), they are simply ignored.
利用可能な範囲を超えているBYXXXパラメーター値（つまり、2月にbymonthday = "30"）が見つかった場合、それらは単に無視されます。
Byxxx parameters modify the recurrence in some manner. Byxxx rule parts for a period of time which is the same or greater than the frequency generally reduce or limit the number of occurrences of the recurrence generated. For example, freq="daily" bymonth="1" reduces the number of recurrence instances from all days (if the "bymonth" parameter is not present) to all days in January. Byxxx parameters for a period of time less than the frequency generally increase or expand the number of occurrences of the recurrence. For example, freq="yearly" bymonth="1,2" increases the number of days within the yearly recurrence set from 1 (if "bymonth" parameter is not present) to 2.
BYXXXパラメーターは、何らかの方法で再発を変更します。byxxxは、一般に、生成された再発の発生数を一般に減少または制限する周波数と同じまたは大きい期間パーツをルールします。たとえば、freq = "daily" bymonth = "1"は、すべての日（「bymonth」パラメーターが存在しない場合）から1月のすべての日までの再発インスタンスの数を減らします。byxxxパラメーターは、周波数よりも少ない期間、一般に再発の発生数を増加または拡大します。たとえば、freq = "yearly" bymonth = "1,2"は、1（「bymonth "パラメーターが存在しない場合）から2に設定された年間再発内の日数を増加させます。
If multiple Byxxx parameters are specified, then after evaluating the specified "freq" and "interval" parameters, the Byxxx parameters are applied to the current set of evaluated occurrences in the following order: "bymonth", "byweekno", "byyearday", "bymonthday", "byday", "byhour", "byminute", "bysecond", and "bysetpos"; then "count" and "until" are evaluated.
複数のBYXXXパラメーターが指定されている場合、指定された「FREQ」および「間隔」パラメーターを評価した後、BYXXXパラメーターは、次の順序で現在の評価された発生セットに適用されます。「bymonthday "、" byday "、" byhour "、" byminute "、" bysecond "、および" bysetpos ";次に、「カウント」と「 'まで」が評価されます。
Here is an example of evaluating multiple Byxxx parameters.
複数のBYXXXパラメーターを評価する例を以下に示します。
<time dtstart="19970105T083000" duration="10M"
freq="yearly" interval="2" bymonth="1" byday="SU"
byhour="8,9" byminute="30">
First, the interval="2" would be applied to freq="yearly" to arrive at "every other year." Then, bymonth="1" would be applied to arrive at "every January, every other year." Then, byday="SU" would be applied to arrive at "every Sunday in January, every other year." Then, byhour="8,9" would be applied to arrive at "every Sunday in January at 8 AM and 9 AM, every other year." Then, byminute="30" would be applied to arrive at "every Sunday in January at 8:30 AM and 9:30 AM, every other year." Then the second is derived from "dtstart" to end up in "every Sunday in January from 8:30:00 AM to 8:40:00 AM, and from and 9:30:00 AM to 9:40:00 AM, every other year." Similarly, if the "byminute", "byhour", "byday", "bymonthday", or "bymonth" parameter were missing, the appropriate minute, hour, day, or month would have been retrieved from the "dtstart" parameter.
まず、interval = "2"がfreq = "yearly"に適用され、「隔年」に到達します。次に、bymonth = "1"が適用され、「毎年1月、1年ごと」に到着します。その後、誕生= "su"が適用され、「1月の1月、1年ごとに」に到着します。その後、byhour = "8,9"が適用され、「毎週日曜日の午前8時と午前9時に隔年」に到着します。その後、byminute = "30"が適用され、「毎週日曜日の午前8時30分と午前9時30分、隔年」に到着します。2番目は「dtstart」から派生し、1月の毎週日曜日の午前8時30分から午前8時40分まで、そして午前9時30分から午前9時40分から午前9時40分まで派生します。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の再発ルールは、タイムスイッチノードのコンポーネントに特別にマッピングされていません。スイッチルールの順序を使用して以前のルールを使用して時間を除外することにより、例外ルールと同等の機能を達成できます。「サブ」ノード（セクション8を参照）を使用して、複数の出力を同じ後続のノードにリンクすることにより、追加のRDATEルールと同等の機能を達成できます。
The "not-present" output is never true for a time switch. However, it MAY be included to allow switch processing to be more regular.
「存在しない」出力は、タイムスイッチには決して当てはまりません。ただし、スイッチ処理をより定期的にすることを許可するために含まれる場合があります。
(This sub-sub-section is non-normative.)
（このサブサブセクションは非規範的です。）
The specification of recurring events in this section is identical (except for syntax and formatting issues) to that of RFC 2445 [8], with only one additional restriction. That one restriction is that consecutive instances of recurrence intervals may not overlap.
このセクションの定期的なイベントの仕様は、RFC 2445 [8]のそれと同一（構文とフォーマットの問題を除く）であり、追加の制限は1つだけです。その1つの制限は、再発間隔の連続したインスタンスが重複しない可能性があるということです。
It was a matter of some debate, during the design of CPL, whether the entire iCalendar COS recurrence specification should be included in CPL, or whether only a subset should be included. It was eventually decided that compatibility between the two protocols was of primary importance. This imposes some additional implementation issues on implementors of CPL servers.
CPLの設計中の議論の問題でした。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の再発によって定義された間隔のいずれか内にあるかどうかを判断することは不可能であると思われます。主な懸念は次のとおりです。
o The "count" parameter cannot be checked in constant running time, since it requires that the server enumerate all recurrences from "dtstart" to the present time, in order to determine whether the current recurrence satisfies the parameter. However, a server can expand a "count" parameter once, off-line, to determine the date of the last recurrence. This date can then be treated as a virtual "until" parameter for the server's internal processing.
o 「count」パラメーターは、現在の再発がパラメーターを満たすかどうかを判断するために、サーバーが「dtstart」から現在までのすべての再発を列挙する必要があるため、一定の実行時間でチェックすることはできません。ただし、サーバーは「カウント」パラメーターをオフラインで1回展開して、最後の再発の日付を決定できます。この日付は、サーバーの内部処理のパラメーターまで仮想的な「まで」として扱うことができます。
o Similarly, the "bysetpos" parameter requires that the server enumerate all instances of the occurrence from the start of the current recurrence set until the present time. This requires somewhat more complex pre-processing, but generally, a single recurrence with a "bysetpos" parameter can be split up into several recurrences without them.
o 同様に、「bysetpos」パラメーターでは、サーバーが現在の回復の開始から現在までの発生のすべてのインスタンスを列挙する必要があります。これにはやや複雑な前処理が必要ですが、一般に、「bysetpos」パラメーターを使用した単一の再発は、それらなしでいくつかの再発に分割できます。
o Finally, constant running time of time switches also requires that a candidate starting time for a recurrence can be established quickly and uniquely, to check whether it satisfies the other restrictions. This requires that a recurrence's duration not be longer than its repetition interval, so that a given instant cannot fall within several consecutive potential repetitions of the recurrence. The restriction that consecutive intervals not overlap partially satisfies this condition, but does not fully ensure it. Again, to some extent pre-processing can help resolve this.
o 最後に、一定の実行時間スイッチを使用すると、他の制限を満たすかどうかを確認するために、候補者の再発時間を迅速かつ一意に確立できる必要があります。これには、再発の期間が繰り返し間隔より長くないため、特定のインスタントが再発のいくつかの連続した潜在的な繰り返しに陥ることはできません。連続した間隔が重複しないという制限は、この状態を部分的に部分的に満たしますが、それを完全に保証しません。繰り返しますが、ある程度の前処理はこれを解決するのに役立ちます。
The algorithm given in Appendix A runs in constant time after these pre-processing steps.
付録Aに示されているアルゴリズムは、これらの前処理手順の後、一定の時間で実行されます。
Servers ought to check that recurrence rules do not create any absurd run-time or memory requirements, and reject those that do, just as they ought to check that CPL scripts in general are not absurdly large.
サーバーは、CPLスクリプトが一般的に不条理ではないことを確認する必要があるように、再発ルールが不条理な実行時間またはメモリの要件を作成しないことを確認し、実行するものを拒否する必要があります。
Priority switches allow a CPL script to make decisions based on the priority specified for the original call. They are summarized in Figure 8. They are dependent on the underlying signalling protocol.
優先スイッチにより、CPLスクリプトは、元の呼び出しに指定された優先度に基づいて決定を下すことができます。それらは図8に要約されています。これらは、基礎となるシグナル伝達プロトコルに依存しています。
Node: "priority-switch" Outputs: "priority" Specific priority to match Parameters: None
ノード：「優先順位スイッチ」出力：「優先度」特定の優先度パラメーターを一致させる：なし
Output: "priority" Parameters: "less" Match if priority is less than that specified "greater" Match if priority is greater than that specified "equal" Match if priority is equal to that specified
出力：「優先度」パラメーター：優先度が指定されている場合は、指定された「グレート」マッチが指定されている場合は、優先度が指定されている場合は、優先順位が指定されている場合が優先度が大きい場合、「より少ない」一致
Figure 8: Syntax of the "priority-switch" node
図8：「優先順位スイッチ」ノードの構文
Priority switches take no parameters.
優先スイッチはパラメーターを取りません。
The "priority" tag takes one of the three parameters "greater", "less", or "equal". The values of these parameters are one of the following priorities: in decreasing order, "emergency", "urgent", "normal", and "non-urgent". These values are matched in a case-insensitive manner. Outputs with the "less" parameter are taken if the priority of the call is less than the priority given in the argument, and so forth.
「優先度」タグは、3つのパラメーターのいずれかを「大きく」、「Less」、または「等しい」とします。これらのパラメーターの値は、次の優先事項の1つです。順序の減少、「緊急」、「緊急」、「通常」、「非緊急」。これらの値は、ケースに依存しない方法で一致します。コールの優先順位が引数で与えられた優先順位よりも少ない場合など、「少ない」パラメーターを使用した出力が取得されます。
If no priority is specified in a message, the priority is considered to be "normal". If an unknown priority is specified in the call, it is considered to be equivalent to "normal" for the purposes of "greater" and "less" comparisons, but it is compared literally for "equal" comparisons.
メッセージで優先度が指定されていない場合、優先順位は「正常」と見なされます。コールで未知の優先度が指定されている場合、「より大きな」と「少ない」比較の目的では「正常」に相当すると見なされますが、文字通り「等しい」比較と比較されます。
Since every message has a priority, the "not-present" output is never true for a priority switch. However, it MAY be included, to allow switch processing to be more regular.
すべてのメッセージには優先事項があるため、「存在しない」出力は、優先順位スイッチには決して当てはまりません。ただし、スイッチ処理がより定期的になるようにするために含まれる場合があります。
The priority of a SIP message corresponds to the "Priority" header in the initial "INVITE" message.
SIPメッセージの優先度は、最初の「招待」メッセージの「優先度」ヘッダーに対応します。
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.
定義された3種類の位置ノードがあります。明示的な場所は、現在の場所セットに文字通り指定された場所を追加し、場所の検索はいくつかの外部ソースから場所を取得し、場所フィルターは指定された基準に基づいてセットから場所を削除します。
Explicit location nodes specify a location literally. Their syntax is described in Figure 9.
明示的な位置ノードは、文字通り場所を指定します。それらの構文については、図9で説明しています。
Explicit location nodes are dependent on the underlying signalling protocol.
明示的な位置ノードは、基礎となるシグナル伝達プロトコルに依存します。
Node: "location" Outputs: None (Next node follows directly) Next node: Any node Parameters: "url" URL of address to add to location set "priority" Priority of this location (0.0-1.0) "clear" Whether to clear the location set before adding the new value
ノード：「場所」出力：なし（次のノードは直接続く）次のノード：任意のノードパラメーター：「URL」アドレスのURLこの場所の「優先度」の優先度（0.0-1.0）「クリア」新しい値を追加する前に設定された場所
Figure 9: Syntax of the "location" node
図9：「場所」ノードの構文
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.
明示的な位置ノードには、3つのノードパラメーターがあります。必須の「URL」パラメーターの値は、ロケーションセットに追加するアドレスのURLです。ロケーションノードごとに1つのアドレスのみを指定できます。これらのノードをカスケードすることにより、複数の場所を指定できます。
The optional "priority" parameter specifies a priority for the location. Its value is a floating-point number between 0.0 and 1.0. If it is not specified, the server SHOULD assume a default priority of 1.0. The optional "clear" parameter specifies whether the location set should be cleared before adding the new location to it. Its value can be "yes" or "no", with "no" as the default.
オプションの「優先度」パラメーターは、場所の優先度を指定します。その値は、0.0〜1.0の間の浮動小数点数です。指定されていない場合、サーバーはデフォルトの優先度1.0を想定する必要があります。オプションの「クリア」パラメーターは、新しい場所を追加する前に場所セットをクリアする必要があるかどうかを指定します。その値は「はい」または「いいえ」であり、デフォルトとして「いいえ」があります。
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.
基本的な位置ノードには、故障する方法がないため、1つの可能な結果しかありません。（基本的な位置ノードが基礎となるシグナリングプロトコルによってサポートされていない場所を指定した場合、スクリプトサーバーはこれを検出し、スクリプトが送信されたときにユーザーに報告する必要があります。）したがって、XML表現は明示的ではありません出力タグ。<location>タグには、別のノードが直接含まれます。
All SIP locations are represented as URLs, so the locations specified in "location" tags are interpreted directly.
すべてのSIPロケーションはURLとして表されるため、「場所」タグで指定された場所は直接解釈されます。
Locations can also be specified up through external means, through the use of location lookups. The syntax of these tags is given in Figure 10.
場所は、ロケーションルックアップを使用して、外部の手段を通じて指定することもできます。これらのタグの構文を図10に示します。
Location lookup is dependent on the underlying signalling protocol.
ロケーションの検索は、基礎となるシグナル伝達プロトコルに依存します。
Node: "lookup" Outputs: "success" Next node if lookup was successful "notfound" Next node if lookup found no addresses "failure" Next node if lookup failed Parameters: "source" Source of the lookup "timeout" Time to try before giving up on the lookup "clear" Whether to clear the location set before adding the new values
ノード：「ルックアップ」出力：「成功」次のノードルックアップが成功した場合、ルックアップが発見されていない "次のノードルックアップが見つからなかった場合、「障害」次のノードルックアップに失敗した場合：「ルックアップのソース」ソース「タイムアウト」新しい値を追加する前に場所をクリアするかどうかを「クリア」ルックアップをあきらめる
Output: "success" Parameters: none
出力：「成功」パラメーター：なし
Output: "notfound" Parameters: none
出力：「違いない」パラメーター：なし
Output: "failure" Parameters: none
出力：「故障」パラメーター：なし
Figure 10: Syntax of the "lookup" node
図10：「ルックアップ」ノードの構文
Location lookup nodes have one mandatory parameter and two optional parameters. The mandatory parameter is "source", the source of the lookup. This can either be a URI, or a non-URI value. If the value of "source" is a URI, it indicates a location which the CPL server can query to obtain an object with the text/uri-list media type (see the IANA registration of this type, which also appears in RFC 2483 [10]). The query is performed verbatim, with no additional information (such as URI parameters) added. The server adds the locations contained in this object to the location set.
ロケーションルックアップノードには、1つの必須パラメーターと2つのオプションパラメーターがあります。必須パラメーターは、ルックアップのソースである「ソース」です。これは、URIまたは非uri値のいずれかです。「ソース」の値がURIの場合、CPLサーバーがクエリしてテキスト/URIリストメディアタイプのオブジェクトを取得できる場所を示します（このタイプのIANA登録を参照してください。これはRFC 2483に表示されます[10]）。クエリは逐語的に実行され、追加情報（URIパラメーターなど）が追加されていません。サーバーは、このオブジェクトに含まれる場所を場所セットに追加します。
CPL servers MAY refuse to allow URI-based sources for location queries for some or all URI schemes. In this case, they SHOULD reject the script at script upload time.
CPLサーバーは、一部またはすべてのURIスキームのロケーションクエリのURIベースのソースを許可することを拒否する場合があります。この場合、スクリプトのアップロード時間でスクリプトを拒否する必要があります。
There has been discussion of having CPL servers add URI parameters to the location request, so that (for instance) CGI scripts could be used to resolve them. However, the consensus was that this should be a CPL extension, not a part of the base specification.
CPLサーバーがロケーションリクエストにURIパラメーターを追加することについての議論があり、（たとえば）CGIスクリプトを使用してそれらを解決できるようにしました。ただし、コンセンサスは、これがベース仕様の一部ではなく、CPL拡張である必要があるということでした。
Non-URL sources indicate a source not specified by a URL which the server can query for addresses to add to the location set. The only non-URL source currently defined is "registration", which specifies all the locations currently registered with the server.
非URLソースは、サーバーが[アドレス]セットに追加するためにクエリをクエリすることができるURLで指定されていないソースを示しています。現在定義されているURL以外の唯一のソースは「登録」で、現在サーバーに登録されているすべての場所を指定します。
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.
Lookupには、「成功」、「違い」、「失敗」の3つの出力があります。ルックアッププロセスが成功したが、場所が見つからなかった場合、NotFoundが取られます。指定されたタイムアウトを超えたことを含め、何らかの理由でルックアップが失敗した場合に障害が発生します。特定の出力が存在しない場合、スクリプト実行が終了し、デフォルトの動作が実行されます。
For SIP, the "registration" lookup source corresponds to the locations registered with the server using "REGISTER" messages.
SIPの場合、「登録」ルックアップソースは、「登録」メッセージを使用してサーバーに登録されている場所に対応します。
A CPL script can also remove locations from the location set, through the use of the "remove-location" node. The syntax of this node is defined in Figure 11.
CPLスクリプトは、「削除」ノードを使用して、ロケーションセットから場所を削除することもできます。このノードの構文は、図11に定義されています。
The meaning of this node is dependent on the underlying signalling Protocol.
このノードの意味は、基礎となるシグナル伝達プロトコルに依存します。
Node: "remove-location" Outputs: None (Next node follows directly) Next node: Any node Parameters: "location" Location to remove
ノード：「ロケーションの削除」出力：なし（次のノードは直接続きます）次のノード：任意のノードパラメーター：「場所」を削除する
Figure 11: Syntax of the "remove-location" node
図11：「削除」ノードの構文
A "remove-location" node removes locations from the location set. It is primarily useful following a "lookup" node. An example of this is given in Section 12.8.
「削除」ノードは、ロケーションセットから場所を削除します。「ルックアップ」ノードに従って主に役立ちます。この例は、セクション12.8に記載されています。
The "remove-location" node has one optional parameter. The parameter "location" gives the URI of a location to be removed from the set, in a signalling-protocol-dependent manner. If this parameter is not given, all locations are removed from the set.
「削除」ノードには、1つのオプションのパラメーターがあります。パラメーター「場所」は、Signall-Protocol依存的に、セットから削除される場所のURIを提供します。このパラメーターが指定されていない場合、すべての場所がセットから削除されます。
The "remove-location" node has no explicit output tags. In the XML syntax, the XML "remove-location" tag directly encloses the next node's tag.
「削除」ノードには、明示的な出力タグがありません。XML構文では、XMLの「削除」タグが次のノードのタグを直接囲みます。
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マッチングの標準ルールを使用して位置設定と一致します（たとえば、登録を更新するときに連絡先アドレスと一致するように）。
Signalling operation nodes cause signalling events in the underlying signalling protocol. Three signalling operations are defined: "proxy," "redirect," and "reject."
シグナリング操作ノードは、基礎となるシグナル伝達プロトコルにシグナリングイベントを引き起こします。3つのシグナル伝達操作が定義されています：「プロキシ」、「リダイレクト」、および「拒否」。
Proxy causes the triggering call to be forwarded on to the currently specified set of locations. The syntax of the proxy node is given in Figure 12.
プロキシにより、トリガーコールが現在指定されている場所のセットに転送されます。プロキシノードの構文を図12に示します。
The specific signalling events invoked by the "proxy" node are signalling-protocol-dependent, though the general concept should apply to any signalling protocol.
「プロキシ」ノードによって呼び出された特定のシグナル伝達イベントは、シグナリングプロトコル依存ですが、一般的な概念はシグナリングプロトコルに適用する必要があります。
Node: "proxy" Outputs: "busy" Next node if call attempt returned "busy" "noanswer" Next node if call attempt was not answered before timeout "redirection" Next node if call attempt was redirected "failure" Next node if call attempt failed "default" Default next node for unspecified outputs Parameters: "timeout" Time to try before giving up on the call attempt "recurse" Whether to recursively look up redirections "ordering" What order to try the location set in.
ノード：「プロキシ」出力：「Busy」次のノードコール試行が返された場合、「Busy」「NOANSWER」次のノードコール試行が回答されなかった場合、タイムアウト「リダイレクト」「リダイレクト」「次のノード」コール試行がリダイレクトされた場合、「失敗」不明確な出力パラメーターの「デフォルト」デフォルトの次のノードに失敗しました：「タイムアウト」コールの試行をあきらめる前に試行する時間を「再発する」リダイレクトを再帰的に検索するかどうかを「注文するかどうか」を「順序にするかどうか。
Output: "busy" Parameters: none
出力：「ビジー」パラメーター：なし
Output: "noanswer" Parameters: none
出力：「NoAnswer」パラメーター：なし
Output: "redirection" Parameters: none
出力：「リダイレクト」パラメーター：なし
Output: "failure" Parameters: none
出力：「故障」パラメーター：なし
Output: "default" Parameters: none
出力：「デフォルト」パラメーター：なし
Figure 12: Syntax of the "proxy" node
図12：「プロキシ」ノードの構文
After a proxy operation has completed, the CPL server chooses the "best" response to the call attempt, as defined by the signalling protocol or the server's administrative configuration rules.
プロキシ操作が完了した後、CPLサーバーは、シグナリングプロトコルまたはサーバーの管理構成ルールで定義されているように、コール試行に対する「最良の」応答を選択します。
If the call attempt was successful, CPL execution terminates and the server proceeds to its default behavior (normally, to allow the call to be set up). Otherwise, the next node corresponding to one of the "proxy" node's outputs is taken. The "busy" output is followed if the call was busy, "noanswer" is followed if the call was not answered before the "timeout" parameter expired, "redirection" is followed if the call was redirected, and "failure" is followed if the call setup failed for any other reason.
コールの試行が成功した場合、CPLの実行が終了し、サーバーはデフォルトの動作に進みます（通常、コールのセットアップを許可します）。それ以外の場合、「プロキシ」ノードの出力の1つに対応する次のノードが取得されます。「Busy」出力に続いて、コールがビジーである場合、「Timeout」パラメーターが失効する前にコールが応答されなかった場合、「NoAnswer」、「リダイレクト」がコールがリダイレクトされた場合、「障害」が続く場合は従われ、その後に通話が行われた場合、その後に続きます。コールのセットアップは、他の理由で失敗しました。
If one of the conditions above is true, but the corresponding output was not specified, the "default" output of the "proxy" node is followed instead. If there is also no "default" node specified, CPL execution terminates and the server returns to its default behavior (normally, to forward the best response upstream to the originator).
上記の条件のいずれかが真であるが、対応する出力が指定されていない場合、代わりに「プロキシ」ノードの「デフォルト」出力が追跡されます。「デフォルト」ノードが指定されていない場合、CPL実行が終了し、サーバーはデフォルトの動作に戻ります（通常、最適な応答をオリジネーターに転送するため）。
Note: CPL extensions to allow in-call or end-of-call operations will require an additional output, such as "success", to be added.
注：CPL拡張機能は、コールまたはコール終了の操作を許可するには、「成功」などの追加の出力が追加される必要があります。
If no locations were present in the set, or if the only locations in the set were locations to which the server cannot proxy a call (for example, "http" URLs), the "failure" output is taken.
セットにロケーションが存在しない場合、またはセット内の唯一の場所が、サーバーが呼び出しをプロキシできない場所（たとえば、「http」URL）である場合、「障害」出力が取得されます。
Proxy has three optional parameters. The "timeout" parameter specifies the time, as a positive integer number of seconds, to wait for the call to be completed or rejected; after this time has elapsed, the call attempt is terminated and the "noanswer" branch is taken. If this parameter is not specified, the default value is 20 seconds if the "proxy" node has a "noanswer" or "default" output specified; otherwise the server SHOULD allow the call to ring for a reasonably long period of time (to the maximum extent that server policy allows).
プロキシには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つの値を取得できます。これは、サーバーが、初期サーバーから返されたリダイレクト応答のテレフォニーアドレスへのさらなるコールの試みを自動的に試行する必要があるかどうかを指定します。「繰り返し」の値が「はい」である場合、スクリプトへの「リダイレクト」出力が取られないことに注意してください。この場合、この出力は存在しないでください。このパラメーターのデフォルト値は「はい」です。
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番目のオプションパラメーターは「順序付け」です。これには、「パラレル」、「シーケンシャル」、「最初の専用」の3つの値があります。このパラメーターは、ロケーションセットの場所をどの順序で試すかを指定します。Parallelは、それらがすべて同時に試されることを尋ねます。シーケンシャルは、優先度が最も高い人は、最初に試行され、次の優先度が最も優先度が高い人は、成功するか、セットが使い果たされるまで尋ねます。First Onlyは、サーバーにセット内の最高優先度アドレスのみを試すように指示し、出力の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.
プロキシ操作が完了すると、コントロールが他のノードに渡されると、使用されたすべての場所がロケーションセットからクリアされます。つまり、「順序付け」が「並列」または「順次」である場合、位置設定は、順になりやすい場所で空になります。「注文」が「最初の専用」である場合、セット内の最高優先項目はセットから削除されます。（すべての場合において、「HTTP」URISなどの非プロキシ不可能な場所は残ります。）「リダイレクト」出力の場合、コールがリダイレクトされた新しいアドレスがロケーションセットに追加されます。
For SIP, the best response to a "proxy" node is determined by the algorithm of the SIP specification. The node's outputs correspond to the following events:
SIPの場合、「プロキシ」ノードに対する最良の応答は、SIP仕様のアルゴリズムによって決定されます。ノードの出力は、次のイベントに対応しています。
busy: A 486 or 600 response was the best response received for the call request.
ビジー：486または600の応答が、コールリクエストに対して受け取った最良の応答でした。
redirection: A 3xx response was the best response received for the call request.
リダイレクト：3xx応答は、コールリクエストに対して受け取った最良の応答でした。
failure: Any other 4xx, 5xx, or 6xx response was the best response received for the call request.
障害：他の4xx、5xx、または6xx応答は、コールリクエストに対して受け取った最良の応答でした。
no-answer: No final response was received for the call request before the timeout expired.
NO-ANSWER：タイムアウトの有効期限が切れる前に、コールリクエストに対して最終応答は受信されませんでした。
SIP servers SHOULD honor the "q" parameter of SIP registrations when determining location priority.
SIPサーバーは、場所の優先順位を決定するときに、SIP登録の「Q」パラメーターを尊重する必要があります。
Redirect causes the server to direct the calling party to attempt to place its call to the currently specified set of locations. The syntax of this node is specified in Figure 13.
リダイレクトにより、サーバーは、現在指定されている場所のセットへの通話を試みるように向けたパーティに指示します。このノードの構文を図13に指定します。
The specific behavior the redirect node invokes is dependent on the underlying signalling protocol involved, though its semantics are generally applicable.
リダイレクトノードが呼び出す特定の動作は、そのセマンティクスが一般的に適用可能ですが、関連する基礎となるシグナル伝達プロトコルに依存します。
Node: "redirect" Outputs: None (No node may follow) Next node: None Parameters: "permanent" Whether the redirection should be considered permanent
ノード：「リダイレクト」出力：なし（ノードはフォローできない）次のノード：なしパラメーター：「永続的」リダイレクトを永続的と見なすべきかどうか
Figure 13: Syntax of the "redirect" node
図13：「リダイレクト」ノードの構文
Redirect immediately terminates execution of the CPL script, so this node has no outputs and no next node. It has one parameter, "permanent", which specifies whether the result returned should indicate that this is a permanent redirection. The value of this parameter is either "yes" or "no" and its default value is "no."
リダイレクトはすぐにCPLスクリプトの実行を終了するため、このノードには出力も次のノードもありません。1つのパラメーター「永続的」があります。これは、返された結果がこれが永続的なリダイレクトであることを示すかどうかを指定します。このパラメーターの値は「はい」または「いいえ」のいずれかで、そのデフォルト値は「いいえ」です。
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クラスの応答を呼び出し要求に送信する必要があります。「永続的」が「はい」だった場合、サーバーは応答「301」（永続的に移動）を送信する必要があります。そうしないと、「302」（一時的に移動）を送信する必要があります。
Reject nodes cause the server to reject the call attempt. Their syntax is given in Figure 14. The specific behavior they invoke is dependent on the underlying signalling protocol involved, though their semantics are generally applicable.
ノードを拒否すると、サーバーが通話試行を拒否します。それらの構文を図14に示します。彼らが呼び出す特定の動作は、それらのセマンティクスが一般的に適用可能ですが、基礎となるシグナル伝達プロトコルに依存します。
Node: "reject" Outputs: None (No node may follow) Next node: None Parameters: "status" Status code to return "reason" Reason phrase to return
ノード：「拒否」出力：なし（ノードはフォローできない）次のノード：なしパラメーター：「ステータス」ステータスコード「理由」「理由」という理由
Figure 14: Syntax of the "reject" node
図14：「拒否」ノードの構文
A reject node immediately terminates the execution of a CPL script, so this node has no outputs and no next node.
拒否ノードはすぐにCPLスクリプトの実行を終了するため、このノードには出力も次のノードもありません。
This node has two arguments: "status" and "reason". The "status" argument is required, and can take one of the values "busy", "notfound", "reject", "error", or a signalling-protocol-defined status.
このノードには、「ステータス」と「理由」の2つの引数があります。「ステータス」引数が必要であり、値のいずれかを「ビジー」、「非ファウンド」、「拒否」、「エラー」、またはシグネリングプロトコル定義のステータスを取得できます。
The "reason" argument optionally allows the script to specify a reason for the rejection.
「理由」引数は、オプションでスクリプトが拒否の理由を指定できるようにします。
Servers which implement SIP SHOULD also allow the "status" field to be a numeric argument corresponding to a SIP status in the 4xx, 5xx, or 6xx range.
SIPを実装するサーバーは、「ステータス」フィールドを4xx、5xx、または6xx範囲のSIPステータスに対応する数値引数にすることもできます。
They SHOULD send the "reason" parameter in the SIP reason phrase.
SIP理由フレーズに「理由」パラメーターを送信する必要があります。
A suggested mapping of the named statuses is as follows. Servers MAY use a different mapping, though similar semantics SHOULD be preserved.
指定されたステータスの推奨マッピングは次のとおりです。サーバーは異なるマッピングを使用する場合がありますが、同様のセマンティクスを保存する必要があります。
"busy": 486 Busy Here
「ビジー」：486ここで忙しい
"notfound": 404 Not Found
「NotFound」：404は見つかりません
"reject": 603 Decline
「拒否」：603衰退
"error": 500 Internal Server Error
「エラー」：500内部サーバーエラー
In addition to the signalling operations, CPL defines several operations which do not affect and are not dependent on the telephony signalling protocol.
シグナリング操作に加えて、CPLは、影響を受けず、テレフォニーシグナリングプロトコルに依存しないいくつかの操作を定義します。
The mail node causes the server to notify a user of the status of the CPL script through electronic mail. Its syntax is given in Figure 15.
メールノードにより、サーバーは電子メールを介してユーザーにCPLスクリプトのステータスを通知します。その構文を図15に示します。
Node: "mail" Outputs: None (Next node follows directly) Next node: Any node Parameters: "url" Mailto url to which the mail should be sent
ノード：「メール」出力：なし（次のノードは直接続きます）次のノード：任意のノードパラメーター：「url」メールを送信するurl "
Figure 15: Syntax of the "mail" node
図15：「メール」ノードの構文
The "mail" node takes one argument: a "mailto" URL giving the address, and any additional desired parameters, of the mail to be sent. The server sends the message containing the content to the given url; it SHOULD also include other status information about the original call request and the CPL script at the time of the notification.
「メール」ノードは、1つの引数を取ります。アドレスを与える「Mailto」URLと、送信されるメールの追加の望ましいパラメーター。サーバーは、コンテンツを含むメッセージを指定されたURLに送信します。また、通知の時点で、元のコールリクエストとCPLスクリプトに関する他のステータス情報も含める必要があります。
Using a full "mailto" URL rather than just an e-mail address allows additional e-mail headers to be specified, such as <mail url="mailto:jones@example.com?subject=Lookup%20failed" />.
<mail url = "mailto：jones@example.com？subject = lookup％20failed" />など、電子メールアドレスだけでなく完全な「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.
メールノードには、電子メール配信の障害がリアルタイムで確実にわかることがないため、1つの可能な結果しかありません。したがって、そのXML表現には出力タグがありません。<mail>タグには、別のノードタグが直接含まれています。
Note that the syntax of XML requires that ampersand characters, "&", which are used as parameter separators in "mailto" URLs, be quoted as "&" inside parameter values (see Section C.12 of the XML specification [2]).
XMLの構文には、「Mailto」URLのパラメーターセパレーターとして使用されるAmpersand文字「＆」が「＆amp;」として引用されることを必要とすることに注意してください。内部パラメーター値（XML仕様[2]のセクションC.12を参照）。
This section presents suggested guidelines for the mail sent as a result of the "mail" node, for requests triggered by SIP. The message mailed (triggered by any protocol) SHOULD contain all this information, but servers MAY elect to use a different format.
このセクションでは、SIPによってトリガーされたリクエストについて、「メール」ノードの結果として送信されたメールの推奨ガイドラインを示します。郵送されたメッセージ（任意のプロトコルによってトリガーされた）には、このすべての情報が含まれている必要がありますが、サーバーは異なる形式を使用することを選択できます。
1. If the "mailto" URI did not specify a subject header, the subject of the e-mail is "[CPL]", followed by the subject header of the SIP request. If the URI specified a subject header, it is used instead.
1. 「Mailto」URIがサブジェクトヘッダーを指定しなかった場合、電子メールの主題は「[CPL]」であり、SIPリクエストのサブジェクトヘッダーが続きます。URIがサブジェクトヘッダーを指定した場合、代わりに使用されます。
2. The "From" field of the e-mail is set to a CPL server configured address, overriding any "From" field in the "mailto" URI.
2. 電子メールの「From」フィールドは、「Mailto」URIの「フィールド」から「任意」をオーバーライドするCPLサーバー構成アドレスに設定されます。
3. Any "Reply-To" header in the URI is honored. If none is given, then an e-mail-ized version of the origin field of the request is used, if possible (e.g., a SIP "From" header with a sip: URI would be converted to an e-mail address by stripping the URI scheme).
3. URIの「返信」ヘッダーは尊重されます。なしが与えられていない場合、リクエストのオリジンフィールドの電子メール化バージョンが使用されます（例えば、sip "from" sip：sip：uriはストリップによって電子メールアドレスに変換されます。URIスキーム）。
4. If the "mailto" URI specifies a body, it is used. If none was specified, the body SHOULD contain at least the identity of the caller (both the caller's display name and address), the date and time of day, the call subject, and if available, the call priority.
4. 「Mailto」URIが本体を指定する場合、使用されます。何も指定されていない場合、ボディには、少なくとも発信者（発信者のディスプレイ名と住所の両方）、日付と時刻の両方、コールサブジェクト、および利用可能な場合は通話の優先順位が含まれている必要があります。
The server SHOULD honor the user's requested languages, and send the mail notification using an appropriate language and character set.
サーバーは、ユーザーの要求された言語を尊重し、適切な言語と文字セットを使用してメール通知を送信する必要があります。
The Log node causes the server to log information about the call to non-volatile storage. Its syntax is specified in Figure 16.
ログノードにより、サーバーは不揮発性ストレージへの呼び出しに関する情報を記録します。その構文を図16に指定します。
Node: "log" Outputs: None (Next node follows directly) Next node: Any node Parameters: "name" Name of the log file to use "comment" Comment to be placed in log file
ノード：「ログ」出力：なし（次のノードは直接続く）次のノード：任意のノードパラメーター：「name "log fileの名前「コメント」コメントを使用するログファイルに配置する
Figure 16: Syntax of the "log" node
図16：「ログ」ノードの構文
Log takes two arguments, both optional: "name", which specifies the name of the log, and "comment", which gives a comment about the information being logged. Servers SHOULD also include other information in the log, such as the time of the logged event, 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.
ログの名前は論理名のみであり、サーバー上の物理ファイルに必ずしも対応するものではありません。ログファイル名の解釈は、これらのログにアクセスするメカニズムと同様に、定義されたサーバーです。CPLサーバーは、セキュリティ上のファイルが上書きされないように、セキュリティ上の理由から、ローカルファイル名に解釈されていないログ名を直接マップするべきではありません。
A correctly operating CPL server SHOULD NOT ever allow the "log" event to fail. As such, log nodes can have only one possible result, and their XML representation does not have explicit output tags. A CPL <log> tag directly contains another node tag.
正しく操作するCPLサーバーは、「ログ」イベントが失敗することを許可してはなりません。そのため、ログノードには可能な結果が1つしかない可能性があり、XML表現には明示的な出力タグがありません。cpl <log>タグには、別のノードタグが直接含まれています。
XML syntax defines a tree. To allow more general call flow diagrams, and to allow script re-use and modularity, we define subactions.
XML構文はツリーを定義します。より一般的なコールフロー図を許可し、スクリプトの再利用とモジュール性を許可するために、サブ作用を定義します。
Two tags are defined for subactions: subaction definitions and subaction references. Their syntax is given in Figure 17.
サブアクションに対して2つのタグが定義されています：サブアクション定義とサブアクション参照。それらの構文を図17に示します。
Tag: "subaction" Subtags: Any node Parameters: "id" Name of this subaction
タグ：「サブアクション」サブタグ：任意のノードパラメーター：「ID」このサブアクションの名前
Pseudo-node: "sub" Outputs: None in XML tree Parameters: "ref" Name of subaction to execute
擬似ノード：「サブ」出力：XMLツリーパラメーターのなし： "ref" subactionの名前を実行する
Figure 17: Syntax of subactions and "sub" pseudo-nodes
図17：サブ作品と「サブ」擬似ノードの構文
Subactions are defined through "subaction" tags. These tags are placed in the CPL script after any ancillary information (see Section 9), but before any top-level tags. They take one argument: "id", a token indicating a script-chosen name for the subaction. The "id" value for every "subaction" tag in a script MUST be unique within that script.
サブアクションは、「サブアクション」タグを使用して定義されます。これらのタグは、補助情報の後にCPLスクリプトに配置されます（セクション9を参照）が、トップレベルのタグの前に。彼らは1つの議論を取っています：「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アクションで任意の場所を使用できます。1つのパラメーター「Ref」、呼び出されるサブアクションの名前が必要です。「サブ」タグには独自の出力が含まれておらず、代わりにコントロールパスをサブアクションに渡します。
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.
潜水艦の後退のみを許可することで、あらゆる種類の再帰を禁止します。再帰は、非終了または密接なCPLスクリプトの可能性を導入するでしょう。これは、当社の要件が具体的に除外された可能性です。
Every sub MUST refer to a subaction ID defined within the same CPL script. No external links are permitted.
すべてのサブは、同じCPLスクリプト内で定義されているサブアクションIDを参照する必要があります。外部リンクは許可されていません。
Subaction IDs are case sensitive.
サブアクションIDはケースに敏感です。
If any subsequent version or extension defines external linkages, it should probably use a different tag, perhaps XLink [21]. Ensuring termination in the presence of external links is a difficult problem.
後続のバージョンまたは拡張が外部リンケージを定義する場合、おそらく別のタグ、おそらくXlink [21]を使用する必要があります。外部リンクの存在下で終了を確保することは困難な問題です。
No ancillary information is defined in the base CPL specification. If ancillary information, not part of any operation, is found to be necessary for a CPL extension, it SHOULD be placed within this tag.
ベースCPL仕様には補助情報が定義されていません。操作の一部ではない補助情報がCPL拡張に必要であることがわかった場合、このタグ内に配置する必要があります。
The (trivial) definition of the ancillary information tag is given in Figure 18.
補助情報タグの（些細な）定義を図18に示します。
It may be useful to include timezone definitions inside CPL scripts directly, rather than referencing them externally with "tzid" and "tzurl" parameters. If it is, an extension could be defined to include them here.
「Tzid」および「Tzurl」パラメーターで外部から参照するのではなく、CPLスクリプト内に直接TimeZone定義を含めることが役立つ場合があります。もしそうなら、ここにそれらを含めるように拡張機能を定義できます。
Tag: "ancillary" Parameters: None Subtags: None
タグ：「補助」パラメーター：なしサブタグ：なし
Figure 18: Syntax of the "ancillary" tag
図18：「補助」タグの構文
When a CPL node reaches an unspecified output, either because the output tag is not present, or because the tag is present but does not contain a node, the CPL server's behavior is dependent on the current state of script execution. This section gives the operations that should be taken in each case.
CPLノードが出力タグが存在しないため、またはタグが存在しているがノードが含まれていないために不特定の出力に到達すると、CPLサーバーの動作はスクリプト実行の現在の状態に依存します。このセクションでは、それぞれの場合に実行する操作を示します。
no location modifications or signalling operations performed, location set empty: Look up the user's location through whatever mechanism the server would use if no CPL script were in effect. Proxy, redirect, or send a rejection message, using whatever policy the server would use in the absence of a CPL script.
場所の変更やシグナリング操作は実行されません。場所が空に設定されています：CPLスクリプトが有効になっていない場合、サーバーが使用するあらゆるメカニズムを介してユーザーの場所を検索します。CPLスクリプトがないときにサーバーが使用するポリシーを使用して、拒否メッセージをプロキシ、リダイレクト、または送信します。
no location modifications or signalling operations performed, location set non-empty: (This can only happen for outgoing calls.) Proxy the call to the addresses in the location set.
ロケーションの変更やシグナリング操作は実行されません。
location modifications performed, no signalling operations: Proxy or redirect the call, whichever is the server's standard policy, to the addresses in the current location set. If the location set is empty, return a "notfound" rejection.
実行された場所の変更、シグナリング操作なし：現在の位置セットのアドレスに、サーバーの標準ポリシーのいずれかのコールをプロキシまたはリダイレクトします。ロケーションセットが空の場合は、「動かない」拒否を返します。
noanswer output of proxy, no timeout given: (This is a special case.) If the "noanswer" output of a proxy node is unspecified, and no timeout parameter was given to the proxy node, the call should be allowed to ring for the maximum length of time allowed by the server (or the request, if the request specified a timeout).
プロキシのNOANSWER出力、タイムアウトは指定されていません：（これは特別なケースです。）プロキシノードの「ノアアンス」出力が不特定であり、プロキシノードにタイムアウトパラメーターが与えられなかった場合、通話は呼び出しを許可する必要があります。サーバーで許可される最大時間（またはリクエストがタイムアウトを指定した場合）。
proxy operation previously taken: Return whatever the "best" response is of all accumulated responses to the call to this point, according to the rules of the underlying signalling protocol.
以前に取られたプロキシ操作：基礎となるシグナリングプロトコルのルールに従って、この点への呼び出しに対するすべての蓄積された応答の「最良の」応答が何であれ、返します。
Servers MAY support additional CPL features beyond those listed in this document. Some of the extensions which have been suggested are a means of querying how a call has been authenticated, richer control over H.323 addressing, end-system or administrator-specific features, regular-expression matching for strings and addresses, and mid-call or end-of-call controls.
サーバーは、このドキュメントにリストされているものを超えた追加のCPL機能をサポートする場合があります。提案されている拡張機能の一部は、呼び出しがどのように認証されたか、H.323アドレス指定、エンドシステムまたは管理者固有の機能、文字列とアドレスの定期発現マッチング、およびミッドコールの豊富な制御を照会する手段です。またはコールの終了コントロール。
CPL extensions are indicated by XML namespaces [11]. Every extension MUST have an appropriate XML namespace assigned to it. The XML namespace of the extension MUST be different from the XML namespace 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.
CPL拡張機能は、XMLネームスペース[11]で示されています。すべての拡張子には、適切なXMLネームスペースが割り当てられている必要があります。拡張機能のXMLネームスペースは、セクション14で定義されているXMLネームスペースとは異なる必要があります。このドキュメントで定義されているCPLスキーマの構文またはセマンティクスを変更してはなりません。拡張機能の一部であるすべてのXMLタグと属性は、それらをその名前空間内に配置するために適切に適格でなければなりません。
Tags or attributes in a CPL script which are in the global namespace (i.e., not associated with any namespace) are equivalent to tags and attributes in the CPL namespace "urn:ietf:params:xml:ns:cpl".
グローバル名空間にあるCPLスクリプトのタグまたは属性（つまり、名前空間に関連付けられていない）は、CPL名空間のタグと属性に相当します。
A CPL script SHOULD NOT specify any namespaces it does not use. For compatibility with non-namespace-aware parsers, a CPL script MAY omit the base CPL namespace for a script which does not use any extensions.
CPLスクリプトは、使用していない名前空間を指定してはなりません。NAMESSPACEで認識されていないパーサーとの互換性のために、CPLスクリプトは、拡張機能を使用しないスクリプトのベースCPL名空間を省略する場合があります。
A CPL server MUST reject any script containing a reference to a namespace it does not understand. It MUST reject any script containing an extension tag or attribute that is not qualified to be in an appropriate namespace.
CPLサーバーは、わからない名前空間への参照を含むスクリプトを拒否する必要があります。適切な名前スペースにある資格がない拡張タグまたは属性を含むスクリプトを拒否する必要があります。
A syntax such as
次のような構文
<extension-switch>
<extension has="http://www.example.com/foo">
[extended things]
</extension>
<otherwise>
[non-extended things]
</otherwise>
</extension-switch>
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スキーマでは、3つの抽象要素、つまり「TopLevelaction」、「Switch」、および「Action」を紹介します。これには、抽象的なタイプ「TopLevelactionType」、「SwitchType」、および「ActionType」があります。CPL拡張機能の上位レベルのアクションは、抽象「Toplevelaction」要素の補充グループとして定義され、型を「ToplevelactionType」から拡張する必要があります。CPL拡張子内のスイッチは、抽象「スイッチ」要素の補充グループとして定義され、型を「switchType」から延長する必要があります。CPL拡張機能のアクションは、抽象的な「アクション」要素の補充グループとして定義され、型を「ActionType」から延長する必要があります。
The script in Figure 19 is a simple script that redirects all calls to a single fixed location.
図19のスクリプトは、すべての呼び出しを単一の固定場所にリダイレクトする簡単なスクリプトです。
<?xml version="1.0" encoding="UTF-8"?>
<cpl xmlns="urn:ietf:params:xml:ns:cpl"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="urn:ietf:params:xml:ns:cpl cpl.xsd ">
<incoming>
<location url="sip:smith@phone.example.com">
<redirect/>
</location>
</incoming>
</cpl>
Figure 19: Example Script: Call Redirect Unconditional
図19：例：スクリプトの例：CALL REDIRECT UNCONDITIONAL
The script in Figure 20 illustrates some more complex behavior. We see an initial proxy attempt to one address, with further operations if that fails. We also see how several outputs take the same action subtree, through the use of subactions.
図20のスクリプトは、より複雑な動作を示しています。1つのアドレスに対する最初のプロキシの試みが見られ、それが失敗した場合はさらなる操作があります。また、サブアクションを使用して、いくつかの出力が同じアクションサブツリーをどのように取るかを確認します。
<?xml version="1.0" encoding="UTF-8"?>
<cpl xmlns="urn:ietf:params:xml:ns:cpl"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="urn:ietf:params:xml:ns:cpl cpl.xsd ">
<subaction id="voicemail">
<location url="sip:jones@voicemail.example.com">
<proxy/>
</location>
</subaction>
<incoming>
<location url="sip:jones@jonespc.example.com">
<proxy timeout="8">
<busy>
<sub ref="voicemail"/>
</busy>
<noanswer>
<sub ref="voicemail"/>
</noanswer>
</proxy>
</location>
</incoming>
</cpl>
Figure 20: Example Script: Call Forward Busy/No Answer
図20：サンプルスクリプト：フォワードビジー/回答なし
The script in Figure 21 illustrates further proxy behavior. The server initially tries to proxy to a single address. If this attempt is redirected, a new redirection is generated using the locations returned. In all other failure cases for the proxy node, a default operation -- forwarding to voicemail -- is performed.
図21のスクリプトは、さらにプロキシの動作を示しています。サーバーは最初、単一のアドレスにプロキシを試みます。この試行がリダイレクトされた場合、返された場所を使用して新しいリダイレクトが生成されます。プロキシノードの他のすべての障害ケースでは、デフォルトの操作（ボイスメールへの転送）が実行されます。
<?xml version="1.0" encoding="UTF-8"?>
<cpl xmlns="urn:ietf:params:xml:ns:cpl"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="urn:ietf:params:xml:ns:cpl cpl.xsd ">
<incoming>
<location url="sip:jones@jonespc.example.com">
<proxy>
<redirection>
<redirect/>
</redirection>
<default>
<location url="sip:jones@voicemail.example.com">
<proxy/>
</location>
</default>
</proxy>
</location>
</incoming>
</cpl>
Figure 21: Example Script: Call Forward: Redirect and Default
The script in Figure 22 illustrates address switches and call rejection, in the form of a call screening script. Note also that because the address-switch lacks an "otherwise" clause, if the initial pattern does not match, the script does not define any operations. The server therefore proceeds with its default behavior, which would presumably be to contact the user.
図22のスクリプトは、コールスクリーニングスクリプトの形で、アドレススイッチとコール拒否を示しています。また、アドレススイッチには「それ以外の」句がないため、初期パターンが一致しない場合、スクリプトは操作を定義しないことに注意してください。したがって、サーバーはデフォルトの動作を進めます。これは、おそらくユーザーに連絡するためです。
<?xml version="1.0" encoding="UTF-8"?>
<cpl xmlns="urn:ietf:params:xml:ns:cpl"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="urn:ietf:params:xml:ns:cpl cpl.xsd ">
<incoming>
<address-switch field="origin" subfield="user">
<address is="anonymous">
<reject status="reject" reason="I reject anonymous calls"/>
</address>
</address-switch>
</incoming>
</cpl>
Figure 22: Example Script: Call Screening
図22：サンプルスクリプト：コールスクリーニング
The script in Figure 23 illustrates service selection based on a call's priority value and language settings. If the call request had a priority of "urgent" or higher, the default script behavior is performed. Otherwise, the language field is checked for the language "es" (Spanish). If it is present, the call is proxied to a Spanish-speaking operator; other calls are proxied to an English-speaking operator.
図23のスクリプトは、通話の優先値と言語設定に基づいたサービスの選択を示しています。コールリクエストの優先順位が「緊急」以上の場合、デフォルトのスクリプト動作が実行されます。それ以外の場合、言語フィールドは言語「es」（スペイン語）のチェックされます。それが存在する場合、呼び出しはスペイン語を話すオペレーターにプロキシ化されます。その他の呼び出しは、英語を話すオペレーターにプロキシ化されています。
<?xml version="1.0" encoding="UTF-8"?>
<cpl xmlns="urn:ietf:params:xml:ns:cpl"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="urn:ietf:params:xml:ns:cpl cpl.xsd ">
<incoming>
<priority-switch>
<priority greater="urgent"/>
<otherwise>
<language-switch>
<language matches="es">
<location url="sip:spanish@operator.example.com">
<proxy/>
</location>
</language>
<otherwise>
<location url="sip:english@operator.example.com">
<proxy/>
</location>
</otherwise>
</language-switch>
</otherwise>
</priority-switch>
</incoming>
</cpl>
Figure 23: Example Script: Priority and Language Routing
図23：例：スクリプト：優先度と言語ルーティング
The script in Figure 24 illustrates a script filtering outgoing calls, in the form of a script which prevent 1-900 (premium) calls from being placed. This script also illustrates subdomain matching.
図24のスクリプトは、1-900（プレミアム）呼び出しが配置されないようなスクリプトの形式でのスクリプトフィルタリングの発信コールを示しています。このスクリプトは、サブドメインのマッチングも示しています。
<?xml version="1.0" encoding="UTF-8"?>
<cpl xmlns="urn:ietf:params:xml:ns:cpl"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="urn:ietf:params:xml:ns:cpl cpl.xsd ">
<outgoing>
<address-switch field="original-destination" subfield="tel">
<address subdomain-of="1900">
<reject status="reject"
reason="Not allowed to make 1-900 calls."/>
</address>
</address-switch>
</outgoing>
</cpl>
Figure 24: Example Script: Outgoing Call Screening
図24：例：スクリプト：発信コールスクリーニング
Figure 25 illustrates time-based conditions and timezones.
図25は、時間ベースの条件とタイムゾーンを示しています。
<?xml version="1.0" encoding="UTF-8"?>
<cpl xmlns="urn:ietf:params:xml:ns:cpl"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="urn:ietf:params:xml:ns:cpl cpl.xsd ">
<incoming>
<time-switch tzid="America/New_York"
tzurl="http://zones.example.com/tz/America/New_York">
<time dtstart="20000703T090000" duration="PT8H" freq="weekly"
byday="MO,TU,WE,TH,FR">
<lookup source="registration">
<success>
<proxy/>
</success>
</lookup>
</time>
<otherwise>
<location url="sip:jones@voicemail.example.com">
<proxy/>
</location>
</otherwise>
</time-switch>
</incoming>
</cpl>
Figure 25: Example Script: Time-of-day Routing
図25：例：スクリプト：時刻のルーティング
Figure 26 illustrates filtering operations on the location set. In this example, we assume that version 0.9beta2 of the "Inadequate Software SIP User Agent" mis-implements some features, and so we must work around its problems. We know that it cannot talk successfully to one particular mobile device we may have registered, so we remove that location from the location set. Once this operation has been completed, call setup is allowed to proceed normally.
図26は、ロケーションセットのフィルタリング操作を示しています。この例では、「不十分なソフトウェアSIPユーザーエージェント」のバージョン0.9Beta2がいくつかの機能を誤って誤っているため、問題を回避する必要があると仮定しています。登録した可能性のある特定のモバイルデバイスと正常に通信できないことがわかっているため、場所セットからその場所を削除します。この操作が完了したら、コールセットアップが正常に進行することが許可されます。
<?xml version="1.0" encoding="UTF-8"?>
<cpl xmlns="urn:ietf:params:xml:ns:cpl"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="urn:ietf:params:xml:ns:cpl cpl.xsd ">
<incoming>
<string-switch field="user-agent">
<string is="Inadequate Software SIP User Agent/0.9beta2">
<lookup source="registration">
<success>
<remove-location location="sip:me@mobile.provider.net">
<proxy/>
</remove-location>
</success>
</lookup>
</string>
</string-switch>
</incoming>
</cpl>
Figure 26: Example Script: Location Filtering
図26：サンプルスクリプト：ロケーションフィルタリング
Figure 27 illustrates non-signalling operations; in particular, alerting a user by electronic mail if the lookup server failed. The primary motivation for having the "mail" node is to allow this sort of out-of-band notification of error conditions, as the user might otherwise be unaware of any problem.
図27は、非署名操作を示しています。特に、ルックアップサーバーが失敗した場合、電子メールでユーザーに警告します。「メール」ノードを持っている主な動機は、ユーザーが問題に気付かない可能性があるため、この種のバンド外の通知を許可することです。
<?xml version="1.0" encoding="UTF-8"?>
<cpl xmlns="urn:ietf:params:xml:ns:cpl"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="urn:ietf:params:xml:ns:cpl cpl.xsd ">
<incoming>
<lookup
source="http://www.example.com/cgi-bin/locate.cgi?user=mary"
timeout="8">
<success>
<proxy/>
</success>
<failure>
<mail url="mailto:mary@example.com?subject=Lookup%20failed"/>
</failure>
</lookup>
</incoming>
</cpl>
Figure 27: Example Script: Non-signalling Operations
図27：例：スクリプト：非署名操作
The example in Figure 28 shows a hypothetical extension that implements distinctive ringing. The XML namespace "http://www.example.com/distinctive-ring" specifies a new node named "ring".
図28の例は、特徴的な鳴きを実装する仮想的な拡張を示しています。XML名空間「http://www.example.com/distinctive-ring」は、「リング」という名前の新しいノードを指定します。
<?xml version="1.0" encoding="UTF-8"?>
<xs:schema targetNamespace="http://www.example.com/distinctive-ring"
xmlns="http://www.example.com/distinctive-ring"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns:CPL="urn:ietf:params:xml:ns:cpl"
elementFormDefault="qualified"
attributeFormDefault="unqualified">
<xs:import namespace="urn:ietf:params:xml:ns:cpl"
schemaLocation="cpl.xsd"/>
<xs:complexType name="DRingAction">
<xs:complexContent>
<xs:extension base="CPL:ActionType">
<xs:attribute name="ringstyle" type="xs:string"
use="optional"/>
</xs:extension>
</xs:complexContent>
</xs:complexType>
<xs:element name="ring" type="DRingAction"
substitutionGroup="CPL:action"/>
</xs:schema>
<?xml version="1.0" encoding="UTF-8"?>
<cpl xmlns="urn:ietf:params:xml:ns:cpl"
xmlns:dr="http://www.example.com/distinctive-ring"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="urn:ietf:params:xml:ns:cpl cpl.xsd
http://www.example.com/distinctive-ring distinctive-ring.xsd">
<incoming>
<address-switch field="origin">
<address is="sip:boss@example.com">
<dr:ring ringstyle="warble"/>
</address>
</address-switch>
</incoming>
</cpl>
Figure 28: Example Schema and Script: Hypothetical Distinctive-Ringing Extension
図28：スキーマとスクリプトの例：仮説的な特徴的なリンギング拡張
The example in Figure 29 implements a hypothetical new attribute for address switches, to allow regular-expression matches. It defines a new attribute "regex" for the standard "address" node.
図29の例は、定期的な発現マッチを可能にするために、アドレススイッチの仮説的な新しい属性を実装しています。標準の「アドレス」ノードの新しい属性「Regex」を定義します。
<?xml version="1.0" encoding="UTF-8"?>
<cpl xmlns="urn:ietf:params:xml:ns:cpl"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="urn:ietf:params:xml:ns:cpl cpl.xsd ">
<incoming>
<address-switch field="origin" subfield="user"
xmlns:re="http://www.example.com/regex">
<address re:regex="(.*.smith|.*.jones)">
<reject status="reject"
reason="I don't want to talk to Smiths or Joneses"/>
</address>
</address-switch>
</incoming>
</cpl>
Figure 29: Example Script: Hypothetical Regular-Expression Extension
図29：例：スクリプト：仮説的な定期発現拡張
Finally, Figure 30 is a complex example which shows the sort of sophisticated behavior that can be achieved by combining CPL nodes. In this case, the user attempts to have his calls reach his desk; if he does not answer within a small amount of time, calls from his boss are forwarded to his mobile phone, and all other calls are directed to voicemail. If the call setup failed, no operation is specified, so the server's default behavior is performed.
最後に、図30は、CPLノードを組み合わせることで達成できる洗練された動作の種類を示す複雑な例です。この場合、ユーザーは自分の電話に机に届かせようとします。彼が少量の時間内に答えない場合、彼の上司からの電話は彼の携帯電話に転送され、他のすべての電話はボイスメールに向けられます。コールのセットアップが失敗した場合、操作は指定されていないため、サーバーのデフォルト動作が実行されます。
<?xml version="1.0" encoding="UTF-8"?>
<cpl xmlns="urn:ietf:params:xml:ns:cpl"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="urn:ietf:params:xml:ns:cpl cpl.xsd ">
<subaction id="voicemail">
<location url="sip:jones@voicemail.example.com">
<redirect />
</location>
</subaction>
<incoming>
<location url="sip:jones@phone.example.com">
<proxy timeout="8">
<busy>
<sub ref="voicemail" />
</busy>
<noanswer>
<address-switch field="origin">
<address is="sip:boss@example.com">
<location url="tel:+19175551212">
<proxy />
</location>
</address>
<otherwise>
<sub ref="voicemail" />
</otherwise>
</address-switch>
</noanswer>
</proxy>
</location>
</incoming>
</cpl>
Figure 30: Example Script: A Complex Example
図30：例の例：複雑な例
CPL is designed to allow services to be specified in a manner which prevents potentially hostile or mis-configured scripts from launching security attacks, including denial-of-service attacks. Because script runtime is strictly bounded by acyclicity, and because the number of possible script operations are strictly limited, scripts should not be able to inflict damage upon a CPL server.
CPLは、サービスの拒否攻撃を含む、敵対的または誤って構成されているスクリプトがセキュリティ攻撃を開始するのを防ぐ方法でサービスを指定できるように設計されています。スクリプトのランタイムはaycycity性によって厳密に制限されているため、および考えられるスクリプト操作の数が厳密に制限されているため、スクリプトはCPLサーバーに損傷を与えることはできません。
Because scripts can direct users' telephone calls, the method by which scripts are transmitted from a client to a server MUST be strongly authenticated. Such a method is not specified in this document.
スクリプトはユーザーの電話を指示できるため、スクリプトがクライアントからサーバーに送信される方法は、強く認証される必要があります。このような方法は、このドキュメントでは指定されていません。
Script servers SHOULD allow server administrators to control the details of what CPL operations are permitted.
スクリプトサーバーでは、サーバー管理者がCPL操作が許可されていることの詳細を制御できるようにする必要があります。
This document registers a new MIME type, application/cpl+xml, and a new URN per RFC 2141 [12], RFC 2648 [13], and RFC 3688 [14].
このドキュメントは、新しいMIMEタイプ、アプリケーション/CPL XML、およびRFC 2141 [12]、RFC 2648 [13]、およびRFC 3688 [14]ごとの新しいurnを登録します。
The XML namespace urn:ietf:params:xml:ns:cpl will only refer to the version of CPL in this document and will not change. Any CPL enhancements MUST be made by extensions and MUST have different namespaces.
XML NameSpace URN：IETF：PARAMS：XML：NS：CPLは、このドキュメントのCPLのバージョンのみを参照し、変更されません。CPLの拡張機能は拡張機能によって行われ、異なる名前空間が必要です。
URI: urn:ietf:params:xml:ns:cpl
Registrant Contact: Jonathan Lennox <lennox@cs.columbia.edu>
Xiaotao Wu <xiaotaow@cs.columbia.edu>
Henning Schulzrinne <hgs@cs.columbia.edu>
XML:
XML：
BEGIN
<?xml version="1.0"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML Basic 1.0//EN"
"http://www.w3.org/TR/xhtml-basic/xhtml-basic10.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta http-equiv="content-type"
content="text/html;charset=iso-8859-1"/>
<title>Call Processing Language Namespace</title>
</head>
<body>
<h1>Namespace for Call Processing Language</h1>
<h2>urn:ietf:params:xml:ns:cpl</h2>
<p><a href="ftp://ftp.rfc-editor.org/in-notes/rfc3880.txt">
RFC3880</a>.</p>
</body>
</html>
END
This specification registers XML Schema for CPL, as per the guidelines in [14].
この仕様は、[14]のガイドラインに従って、CPLのXMLスキーマを登録します。
URI: urn:ietf:params:xml:schema:cpl
Registrant contact:
Jonathan Lennox <lennox@cs.columbia.edu>
Xiaotao Wu <xiaotaow@cs.columbia.edu>
Henning Schulzrinne <hgs@cs.columbia.edu>
XML: The XML can be found in Appendix C.
XML：XMLは付録Cにあります。
As an XML type, CPL's MIME registration conforms with "XML Media Types," RFC 3023 [15].
XMLタイプとして、CPLのMIME登録は「XMLメディアタイプ」RFC 3023 [15]に準拠しています。
MIME media type name: application
MIMEメディアタイプ名：アプリケーション
MIME subtype name: cpl+xml
MIMEサブタイプ名：CPL XML
Mandatory parameters: none
必須パラメーター：なし
Optional parameters: charset As for application/xml in RFC 3023.
オプションのパラメーター：RFC 3023のApplication/XMLのcharset。
Encoding considerations: As for application/xml in RFC 3023.
考慮事項のエンコード：RFC 3023のアプリケーション/XMLについて。
Security considerations: See Section 13, and Section 10 of RFC 3023.
セキュリティ上の考慮事項：RFC 3023のセクション13およびセクション10を参照してください。
Interoperability considerations: Different CPL servers may use incompatible address types. However, all potential interoperability issues should be resolvable at the time a script is uploaded; there should be no interoperability issues which cannot be detected until runtime.
相互運用性の考慮事項：異なるCPLサーバーは、互換性のないアドレスタイプを使用する場合があります。ただし、スクリプトがアップロードされた時点では、すべての潜在的な相互運用性の問題は解決可能である必要があります。実行時まで検出できない相互運用性の問題はありません。
Published specification: This document.
公開された仕様：このドキュメント。
Applications which use this media type: SIP proxy servers and other telephony servers, and client software to control their behavior.
このメディアタイプを使用するアプリケーション：SIPプロキシサーバーおよびその他のテレフォニーサーバー、およびクライアントソフトウェアの動作を制御します。
Additional information:
追加情報：
Magic number: None
マジックナンバー：なし
File extension: .cpl or .xml
ファイル拡張子：.cplまたは.xml
Macintosh file type code: "TEXT"
Macintoshファイルタイプコード：「テキスト」
Person and e-mail address for further information:
Jonathan Lennox <lennox@cs.columbia.edu>
Xiaotao Wu <xiaotaow@cs.columbia.edu>
Henning Schulzrinne <hgs@cs.columbia.edu>
Intended usage: COMMON
意図された使用法：共通
Author/Change Controller: The IETF.
著者/変更コントローラー：IETF。
This document was reviewed and commented upon by the IETF IP Telephony Working Group. We specifically acknowledge the following people for their help:
このドキュメントは、IETF IPテレフォニーワーキンググループによってレビューされ、コメントされました。私たちは、次の人々の助けについて具体的に認めます。
The outgoing call screening script was written by Kenny Hom.
発信コールスクリーニングスクリプトは、Kenny Homによって作成されました。
Paul E. Jones contributed greatly to the mappings of H.323 addresses.
Paul E. Jonesは、H.323アドレスのマッピングに大きく貢献しました。
The text of the time-switch section was taken (lightly modified) from RFC 2445 [8], by Frank Dawson and Derik Stenerson.
Time-Switchセクションのテキストは、Frank DawsonとDerik StenersonによってRFC 2445 [8]から撮影されました（軽く変更されました）。
We drew a good deal of inspiration, notably the language's lack of Turing-completeness and the syntax of string matching, from the specification of Sieve [22], a language for user filtering of electronic mail messages.
私たちは、電子メールメッセージのユーザーフィルタリングの言語であるSieve [22]の仕様から、言語のチューリングの完全性の欠如と文字列マッチングの構文、特に多くのインスピレーションを描きました。
Thomas F. La Porta and Jonathan Rosenberg had many useful discussions, contributions, and suggestions.
トーマス・F・ラ・ポルタとジョナサン・ローゼンバーグには、多くの有用な議論、貢献、提案がありました。
Richard Gumpertz performed a very useful last-minute technical and editorial review of the specification.
Richard Gumpertzは、仕様の非常に有用な土壇場の技術的および編集レビューを実施しました。
A. An Algorithm for Resolving Time Switches
A.時間スイッチを解決するためのアルゴリズム
The following algorithm determines whether a given instant falls within a repetition of a "time-switch" recurrence. If the pre-processing described in Section 4.4.1 has been done, it operates in constant time. Open-source Java code implementing this algorithm is available at http://www.cs.columbia.edu/~lennox/Cal-Code/ on the world wide web.
次のアルゴリズムは、与えられたインスタントが「時間切り替え」再発の繰り返し内に収まるかどうかを決定します。セクション4.4.1で説明されている前処理が行われた場合、一定の時間で動作します。このアルゴリズムを実装するオープンソースJavaコードは、World Wide Webでhttp://www.cs.columbia.edu/~lennox/cal-code/で入手できます。
This algorithm is believed to be correct, but this section is non-normative. Section 4.4, and RFC 2445 [8], are the definitive definitions of recurrences.
このアルゴリズムは正しいと考えられていますが、このセクションは非規範的です。セクション4.4、およびRFC 2445 [8]は、再発の決定的な定義です。
1. Compute the time of the call, in the timezone of the time switch.
1. Time Switchのタイムゾーンで、コールの時間を計算します。
2. If the call time is earlier than "dtstart", fail NOMATCH.
2. 呼び出し時間が「dtstart」よりも早い場合は、nomatchに失敗します。
3. If the call time is less than "duration" after dtstart, succeed MATCH.
3. コール時間がDTSTART後の「期間」未満の場合は、一致することを成功させます。
4. Determine the smallest unit specified in a "byxxx" rule or by the "freq." Call this the Minimum Unit. Determine the previous instant (before or equal to the call time) when all the time units smaller than the minimum unit are the same as those of "dtstart." If the minimum unit is a second, this time is the same as the instant. If the minimum unit is a minute or an hour, the minutes or the minutes and hours, respectively, must be the same as "dtstart". For all other minimum units, the time-of-day must be the same as "dtstart." If the minimum unit is a week, the day-of-the-week must be the same as "dtstart." If the minimum unit is a month, the day-of-the-month must be the same as "dtstart." If the minimum unit is a year, the month and day-of-month must both be the same as "dtstart." (Note that this means it may be necessary to roll back more than one minimum unit -- if the minimum unit is a month, then some months do not have a 31st (or 30th or 29th) day; if the minimum unit is a year, then some years do not have a February 29th. In the Gregorian calendar, it is never necessary to roll back more than two months if the minimum unit is a month, or eight years if the minimum unit is a year. Between 1904 and 2096, it is never necessary to roll back more than four years -- the eight-year rollback can only occur when the Gregorian calendar "skips" a leap year.
4. 「byxxx」ルールまたは「freq」によって指定された最小ユニットを決定します。これを最小ユニットと呼びます。最小ユニットよりも小さいすべての時間単位が「dtstart」のユニットと同じである場合、前のインスタント（コール時間以前または等しい）を決定します。最小ユニットが秒の場合、今回はインスタントと同じです。最小ユニットが1分または1時間の場合、それぞれ議事録または数分と時間は「dtstart」と同じでなければなりません。他のすべての最小ユニットについては、時刻は「dtstart」と同じでなければなりません。最小ユニットが1週間の場合、週の日は「dtstart」と同じでなければなりません。最小ユニットが月の場合、月の日は「dtstart」と同じでなければなりません。最小ユニットが1年の場合、月と月の日は両方とも「dtstart」と同じでなければなりません。（これは、最小ユニットが1か月である場合、最小ユニットが1か月である場合、数か月は31日（または30日または29日）の日がない場合、最小ユニットが1年である場合、これは必要になることを意味することに注意してください。最小ユニットが1年である場合、その後、数年は2月29日にはありません。グレゴリオカレンダーでは、最低ユニットが1か月である場合、または最低ユニットが1年である場合は8年以上ロールバックする必要はありません。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.
5. 候補者の開始時間と呼び出し時間が期間を超える時間が長い場合、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.
6. 候補の開始時間が再発の「ut ut "パラメーター（または仮想」まで「「count」からオフラインを計算する）よりも遅い場合、nomatchに失敗します。
7. Call the unit of the "freq" parameter of the recurrence the Frequency Unit. Determine the frequency unit enclosing the Candidate Start Time, and that enclosing "dtstart". Calculate the number of frequency units that have passed between these two times. If this is not a multiple of the "interval" parameter, fail NOMATCH.
7. 周波数単位の再発の「freq」パラメーターの単位を呼び出します。候補の開始時間を囲む周波数ユニットと、「dtstart」を囲むことを決定します。これら2回を通過した周波数単位の数を計算します。これが「間隔」パラメーターの倍数ではない場合は、Nomatchに失敗します。
8. For every "byxxx" rule, confirm that the candidate start time matches one of the options specified by that "byxxx" rule. If so, succeed MATCH.
8. すべての「byxxx」ルールについて、候補の開始時刻が「byxxx」ルールで指定されたオプションの1つと一致することを確認します。もしそうなら、試合を成功させてください。
9. Calculate a previous candidate start time. Repeat until the difference between the candidate start time and the call time is more than the duration. If no candidate start time has been validated, fail NOMATCH.
9. 以前の候補の開始時間を計算します。候補の開始時間と呼び出し時間が期間を超えるまで繰り返します。候補の開始時間が検証されていない場合は、nomatchに失敗します。
B. Suggested Usage of CPL with H.323
B. H.323でのCPLの使用を提案しました
This appendix gives a suggested usage of CPL with H.323 [16]. Study Group 16 of the ITU, which developed H.323, is proposing to work on official CPL mappings for that protocol. This section is therefore not normative.
この付録は、H.323を使用したCPLの推奨される使用法を示しています[16]。H.323を開発したITUの研究グループ16は、そのプロトコルの公式CPLマッピングに取り組むことを提案しています。したがって、このセクションは規範的ではありません。
Address switches are specified in Section 4.1. This section specifies the mapping between H.323 messages and the fields and subfields of address-switches.
アドレススイッチは、セクション4.1で指定されています。このセクションでは、H.323メッセージとアドレススイッチのフィールドとサブフィールドの間のマッピングを指定します。
For H.323, the "origin" address corresponds to the alias addresses in the "sourceAddress" field of the "Setup-UUIE" user-user information element, and to the Q.931 [23] information element "Calling party number." If both fields are present, or if multiple alias addresses for "sourceAddress" are present, which one has priority is a matter of local server policy; the server SHOULD use the same resolution as it would use for routing decisions in this case. Similarly, the "destination" address corresponds to the alias addresses of the "destinationAddress" field, and to the Q.931 information element "Called party number." 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.
H.323の場合、「Origin」アドレスは、「Setup-Uuie」ユーザーユーザー情報要素の「Sourceaddress」フィールドのエイリアスアドレスと、Q.931 [23]情報要素「通話党番号」に対応します。「両方のフィールドが存在する場合、または「sourceaddress」の複数のエイリアスアドレスが存在する場合、優先順位があることはローカルサーバーポリシーの問題です。サーバーは、この場合のルーティング決定に使用するのと同じ解像度を使用する必要があります。同様に、「宛先」アドレスは、「DestivessingAddress」フィールドのエイリアスアドレスと、Q.931情報要素「パーティー番号」と対応します。「元の捨て」アドレスは、存在する場合、「リダイレクト番号」Q.931情報要素に対応しています。それ以外の場合は、「宛先」アドレスと同じです。
The mapping of H.323 addresses into subfields depends on the type of the alias address. An additional subfield type, "alias-type", is defined for H.323 servers, corresponding to the type of the address. Possible values are "dialedDigits", "h323-ID", "url-ID", "transportID", "email-ID", "partyNumber", "mobileUIM", and "Q.931IE". If future versions of the H.323 specification define additional types of alias addresses, those names MAY also be used.
h.323アドレスのサブフィールドへのマッピングは、エイリアスアドレスのタイプに依存します。追加のサブフィールドタイプ「Alias-Type」は、アドレスのタイプに対応するH.323サーバーに対して定義されています。考えられる値は、「DialedDigits」、「H323-ID」、「URL-ID」、「TransportID」、「Email-ID」、「PartyNumber」、「MobileUIM」、および「Q.931IE」です。H.323仕様の将来のバージョンが追加のタイプのエイリアスアドレスを定義する場合、それらの名前も使用できます。
In versions of H.323 prior to version 4, "dialedDigits" was known as "e164". The two names SHOULD be treated as synonyms.
バージョン4以前のH.323のバージョンでは、「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.
H.323メッセージの「アドレスタイプ」サブフィールドの値は、エイリアスタイプが「URL-ID」であり、URLスキームがH323以外のものでない限り、「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.
H.323対応のCPLサーバーは、ルーティングに使用されるプライマリエイリアスのアドレスサブフィールドをマッピングする必要があります。また、プライマリアドレスのサブフィールドが存在しない場合、他のエイリアスからサブフィールドをマッピングする場合があります。
The following mappings are used for H.323 alias types:
次のマッピングは、h.323エイリアスタイプに使用されます。
dialedDigits, partyNumber, mobileUIM, and Q.931IE: the "tel" and "user" subfields are the string of digits, as is the "entire-address" form. The "host" and "port" subfields are not present.
dialeddigits、partynumber、mobileuim、q.931ie：「tel」および「user」サブフィールドは、「全体のアドレス」フォームと同様に、一連の数字です。「ホスト」と「ポート」サブフィールドは存在しません。
url-ID: the same mappings are used as for SIP, in Section 4.1.1.
URL-ID：セクション4.1.1のSIPと同じマッピングが使用されます。
h323-ID: the "user" field is the string of characters, as is the "entire-address" form. All other subfields are not present.
H323-ID：「ユーザー」フィールドは、「Address Whole-Address」フォームと同様に、文字列の文字列です。他のすべてのサブフィールドは存在しません。
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」サブフィールドは存在しません。「Address全体」フォームは、電子メールアドレス全体に対応しています。
transportID: if the TransportAddress is of type "ipAddress," "ipSourceRoute," or "ip6Address," the "host" subfield is set to the "ip" element of the sequence, translated into the standard IPv4 or IPv6 textual representation, and the "port" subfield is set to the "port" element of the sequence represented in decimal. The "tel" and "user" fields are not present. The "entire-address" form is not defined. The representation and mapping of transport addresses is not defined for non-IP addresses.
TransportID：TransportAddressが「iPaddress」、「Ipsourceroute」、または「IP6Address」のタイプの場合、「ホスト」サブフィールドがシーケンスの「IP」要素に設定され、標準のIPv4またはIPv6テキスト表現、およびIPv6テキスト表現、および「ポート」サブフィールドは、小数で表されるシーケンスの「ポート」要素に設定されています。「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に示されているように、これらのURIのCPL「アドレススイッチ」サブフィールドへのマッピングを定義しています。この定義は、RFC 3508 [24]としても利用できます。これは、H.323仕様からの抜粋です。
For h323 URIs, the "user", "host", and "port" subfields are set to the corresponding parts of the H.323 URL. The "tel" subfield is not present. The "entire-address" form corresponds to the entire URI.
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「URL-ID」アドレスエイリアスのH323 URISおよびSIPメッセージのH323 URIの両方に使用できます。
For H.323, the "string-switch" node (see Section 4.2) is used as follows. The field "display" corresponds to the Q.931 information element of the same name, copied verbatim. The fields "subject", "organization", and "user-agent" are not used and are never present.
H.323の場合、「文字列スイッチ」ノード（セクション4.2を参照）を次のように使用します。フィールド「ディスプレイ」は、同じ名前のQ.931情報要素、逐語的にコピーされたものに対応しています。フィールド「サブジェクト」、「組織」、および「ユーザーエージェント」は使用されず、決して存在しません。
The "display" IE is conventionally used for Caller-ID purposes, so arguably it should be mapped to the "display" subfield of an "address-match" with the field "originator". However, since a) it is a message-level information element, not an address-level one, and b) the Q.931 specification [23] says only that "[t]he purpose of the Display information element is to supply display information that may be displayed by the user," it seems to be more appropriate to allow it to be matched in a "string-switch" instead.
「ディスプレイ」IEは従来、発信者とIDの目的で使用されるため、間違いなく、フィールド「オリジネーター」を使用して「アドレスマッチ」の「ディスプレイ」サブフィールドにマッピングする必要があります。ただし、a）アドレスレベルの情報ではなく、メッセージレベルの情報要素であるため、b）Q.931仕様[23]は、「[t]表示情報要素の目的はディスプレイを提供することです。ユーザーが表示される可能性のある情報は、「代わりに「文字列スイッチ」で一致させることがより適切であると思われます。
The language-ranges for the "language-switch" switch are obtained from the H.323 UUIE "language". The switch is not-present if the initial message did not contain this UUIE.
「言語スイッチ」スイッチの言語範囲は、H.323 UUIE「言語」から取得されます。最初のメッセージにこのuuieが含まれていない場合、スイッチは存在しません。
All H.323 messages are considered to have priority "normal" for the purpose of a priority switch (see Section 4.5).
すべてのH.323メッセージは、優先スイッチを目的として優先度「通常」と見なされます（セクション4.5を参照）。
Locations in explicit location nodes (Section 5.1) are specified as URLs. Therefore, all locations added in this manner are interpreted as being of alias type "url-ID" in H.323.
明示的な位置ノード（セクション5.1）の場所は、URLとして指定されています。したがって、この方法で追加されたすべての場所は、H.323のエイリアスタイプ「URL-ID」であると解釈されます。
Specifications of other H.323 address alias types will require a CPL extension (see Section 11).
他のH.323アドレスエイリアスタイプの仕様には、CPL拡張が必要です（セクション11を参照）。
For location lookup nodes (Section 5.2), the "registration" lookup source corresponds to the locations registered with the server using "RAS" messages.
ロケーションルックアップノード（セクション5.2）の場合、「登録」ルックアップソースは、「RAS」メッセージを使用してサーバーに登録されている場所に対応します。
Location removal nodes (Section 5.3) remove addresses with the alias type "url-ID" using verbatim string matching on the URLs. If a "tel" URL is specified as the location, matching addresses (ignoring visual separators) with the alias types "dialedDigits" ("e164"), "partyNumber", "mobileUIM", or "Q.931IE" are also removed. No mechanism is provided to remove other alias types.
位置削除ノード（セクション5.3）は、URLの逐語的な文字列を使用して、エイリアスタイプ「URL-ID」でアドレスを削除します。「Tel」URLが場所として指定されている場合、アドレス（視覚的セパレーターを無視する）とエイリアスタイプ「DialedDigits」（「E164」）、「PartyNumber」、「MobileUIM」、または「Q.931IE」も削除されます。他のエイリアスタイプを削除するメカニズムは提供されていません。
C. The XML Schema for CPL
C. CPLのXMLスキーマ
This section includes a full XML Schema describing the XML syntax of CPL. Every script submitted to a CPL server SHOULD comply with this XML Schema. When parsing scripts comply with the CPL DTD in earlier documents, the DOCTYPE lines in the scripts should be ignored. Note that compliance with this schema is not a sufficient condition for correctness of a CPL script, as many of the conditions described in this specification are not expressible in schema syntax. Figure 31 shows the structure of the schema. 'incoming' and 'outgoing' are defined as the substitutionGroup of the 'toplevelaction'. All the switches are defined as the substitutionGroup of the 'switch' element. All the actions are defined as the substitutionGroup of the 'action' element.
このセクションには、CPLのXML構文を説明する完全なXMLスキーマが含まれています。CPLサーバーに提出されたすべてのスクリプトは、このXMLスキーマに準拠する必要があります。解析スクリプトが以前のドキュメントでCPL DTDに準拠している場合、スクリプトのDoctype行は無視する必要があります。この仕様で説明されている条件の多くはスキーマ構文で表現できないため、このスキーマのコンプライアンスはCPLスクリプトの正しさのための十分な条件ではないことに注意してください。図31は、スキーマの構造を示しています。「受信」と「発信」は、「TopLevelaction」のSustitutionGroupとして定義されます。すべてのスイッチは、「スイッチ」要素のASTOMTIONGROUPとして定義されます。すべてのアクションは、「アクション」要素の代替グループとして定義されます。
+---------+ +------+ +--address
+-+ancillary| |switch|** +--------------+ | +-not-present
| +---------+ +---+--+ **|address-switch+-+-+-address
| | * +--------------+ +--otherwise
| +---------+ +----+ | * +--language
+-+subaction+-+Node| | * +---------------+ | +-not-present
| +---------+ +----+ | **|language-switch|-+-+-language
| | * +---------------+ +--otherwise
| | * +--priority
| | * +---------------+ | +-not-present
| | **|priority-switch|-+-+-priority
| | * +---------------+ +--otherwise
| | * +--string
cpl-+ | * +-------------+ | +-not-present
| | **|string-switch|-+ +-string
| | * +-------------+ +--otherwise
| | * +--time
| +--------------+ +-+--+ * +-----------+ | +-not-present
+-+toplevelaction+-+Node| *|time-switch|-+-+-time
+-----*--------+ +-+--+ +-----------+ +--otherwise
* | +--------+ +----+
* | **|location+-|Node|
* | +--------+ * +--------+ +----+
* +--------+ |-+modifier|** +------+ +-success-Node
**|incoming| | +--------+ *-|lookup+-+-notfound-Node
* +--------+ | * +------+ +-failure-Node
* | +---+ * +---------------+ +----+
* +--------+ +-+Sub+-sub **|remove-location+-+Node|
*|outgoing| | +---+ +---------------+ +----+
+--------+ | +---+
| **|log+-Node
| * +---+
| * +----+
| +------+ **|mail+-Node
+-+action|** +----+ +-busy-Node
---- contains +------+ * +-----+ |
**|proxy+----+-noanswer-Node
**** substitutes * +-----+ |
* +--------+ +-failure-Node
**|redirect| |
* +--------+ +-redirection-Node
* +------+ |
*|reject| +-default-Node
+------+
Figure 31: The structure of the XML schema for CPL
BEGIN
<?xml version="1.0" encoding="UTF-8"?>
<xs:schema targetNamespace="urn:ietf:params:xml:ns:cpl"
xmlns="urn:ietf:params:xml:ns:cpl"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
elementFormDefault="qualified"
attributeFormDefault="unqualified">
<xs:complexType name="TopLevelActionType" abstract="true">
<xs:group ref="Node"/>
</xs:complexType>
<xs:element name="toplevelaction" type="TopLevelActionType"/>
<xs:complexType name="ActionType" abstract="true"/>
<xs:element name="action" type="ActionType"/>
<xs:complexType name="SwitchType" abstract="true"/>
<xs:element name="switch" type="SwitchType"/>
<xs:complexType name="ModifierType" abstract="true"/>
<xs:element name="modifier" type="ModifierType"/>
<xs:element name="location" type="LocationType"
substitutionGroup="modifier"/>
<xs:element name="lookup" type="LookupType"
substitutionGroup="modifier"/>
<xs:element name="remove-location" type="RemoveLocationType"
substitutionGroup="modifier"/>
<xs:element name="sub" type="SubAction"/>
<xs:group name="Node">
<xs:choice>
<xs:element ref="switch" minOccurs="0" maxOccurs="1"/>
<xs:element ref="modifier" minOccurs="0" maxOccurs="1"/>
<xs:element ref="sub" minOccurs="0" maxOccurs="1"/>
<xs:element ref="action" minOccurs="0" maxOccurs="1"/>
</xs:choice>
</xs:group>
<xs:complexType name="OtherwiseAction">
<xs:group ref="Node"/>
</xs:complexType>
<xs:complexType name="NotPresentAction">
<xs:group ref="Node"/>
</xs:complexType>
<xs:simpleType name="YesNoType">
<xs:restriction base="xs:NMTOKEN">
<xs:enumeration value="yes"/>
<xs:enumeration value="no"/>
</xs:restriction>
</xs:simpleType>
<xs:simpleType name="StatusType">
<xs:union>
<xs:simpleType>
<xs:restriction base="xs:NMTOKEN">
<xs:enumeration value="busy"/>
<xs:enumeration value="notfound"/>
<xs:enumeration value="reject"/>
<xs:enumeration value="error"/>
</xs:restriction>
</xs:simpleType>
<xs:simpleType>
<xs:restriction base="xs:string"/>
</xs:simpleType>
</xs:union>
</xs:simpleType>
<xs:simpleType name="OrderingType">
<xs:restriction base="xs:NMTOKEN">
<xs:enumeration value="parallel"/>
<xs:enumeration value="sequential"/>
<xs:enumeration value="first-only"/>
</xs:restriction>
</xs:simpleType>
<xs:simpleType name="AddressFieldType">
<xs:union>
<xs:simpleType>
<xs:restriction base="xs:NMTOKEN">
<xs:enumeration value="origin"/>
<xs:enumeration value="destination"/>
<xs:enumeration value="original-destination"/>
</xs:restriction>
</xs:simpleType>
<xs:simpleType>
<xs:restriction base="xs:string"/>
</xs:simpleType>
</xs:union>
</xs:simpleType>
<xs:simpleType name="AddressSubfieldType">
<xs:union>
<xs:simpleType>
<xs:restriction base="xs:NMTOKEN">
<xs:enumeration value="address-type"/>
<xs:enumeration value="user"/>
<xs:enumeration value="host"/>
<xs:enumeration value="port"/>
<xs:enumeration value="tel"/>
<xs:enumeration value="display"/>
<xs:enumeration value="password"/>
<xs:enumeration value="alias-type"/>
</xs:restriction>
</xs:simpleType>
<xs:simpleType>
<xs:restriction base="xs:string"/>
</xs:simpleType>
</xs:union>
</xs:simpleType>
<xs:complexType name="AddressType">
<xs:annotation>
<xs:documentation>Exactly one of the three attributes must
appear</xs:documentation>
</xs:annotation>
<xs:group ref="Node"/>
<xs:attribute name="is" type="xs:string" use="optional"/>
<xs:attribute name="contains" type="xs:string" use="optional">
<xs:annotation>
<xs:documentation>for "display" only</xs:documentation>
</xs:annotation>
</xs:attribute>
<xs:attribute name="subdomain-of" type="xs:string"
use="optional">
<xs:annotation>
<xs:documentation>for "host", "tel" only</xs:documentation>
</xs:annotation>
</xs:attribute>
<xs:anyAttribute namespace="##any" processContents="lax"/>
</xs:complexType>
<xs:complexType name="AddressSwitchType">
<xs:complexContent>
<xs:extension base="SwitchType">
<xs:sequence>
<xs:element name="address" type="AddressType" minOccurs="0"
maxOccurs="unbounded"/>
<xs:sequence minOccurs="0">
<xs:element name="not-present" type="NotPresentAction"/>
<xs:element name="address" type="AddressType"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:element name="otherwise" type="OtherwiseAction"
minOccurs="0"/>
</xs:sequence>
<xs:attribute name="field" type="AddressFieldType"
use="required"/>
<xs:attribute name="subfield" type="AddressSubfieldType"
use="optional"/>
</xs:extension>
</xs:complexContent>
</xs:complexType>
<xs:element name="address-switch" type="AddressSwitchType"
substitutionGroup="switch"/>
<xs:simpleType name="StringFieldType">
<xs:restriction base="xs:NMTOKEN">
<xs:enumeration value="subject"/>
<xs:enumeration value="organization"/>
<xs:enumeration value="user-agent"/>
<xs:enumeration value="display"/>
</xs:restriction>
</xs:simpleType>
<xs:complexType name="StringType">
<xs:group ref="Node"/>
<xs:attribute name="is" type="xs:string" use="optional"/>
<xs:attribute name="contains" type="xs:string" use="optional"/>
<xs:anyAttribute namespace="##any" processContents="lax"/>
</xs:complexType>
<xs:complexType name="StringSwitchType">
<xs:complexContent>
<xs:extension base="SwitchType">
<xs:sequence>
<xs:element name="string" type="StringType" minOccurs="0"
maxOccurs="unbounded"/>
<xs:sequence minOccurs="0">
<xs:element name="not-present" type="NotPresentAction"/>
<xs:element name="string" type="StringType" minOccurs="0"
maxOccurs="unbounded"/>
</xs:sequence>
<xs:element name="otherwise" type="OtherwiseAction"
minOccurs="0"/>
</xs:sequence>
<xs:attribute name="field" type="StringFieldType"
use="required">
<xs:annotation>
<xs:documentation>Strings are matched as case-insensitive
Unicode strings.</xs:documentation>
</xs:annotation>
</xs:attribute>
</xs:extension>
</xs:complexContent>
</xs:complexType>
<xs:element name="string-switch" type="StringSwitchType"
substitutionGroup="switch"/>
<xs:complexType name="LanguageType">
<xs:group ref="Node"/>
<xs:attribute name="matches" type="xs:string" use="required">
<xs:annotation>
<xs:documentation>The value of one of these parameters is a
language-tag, as defined in RFC
3066.</xs:documentation>
</xs:annotation>
</xs:attribute>
<xs:anyAttribute namespace="##any" processContents="lax"/>
</xs:complexType>
<xs:complexType name="LanguageSwitchType">
<xs:complexContent>
<xs:extension base="SwitchType">
<xs:sequence>
<xs:element name="language" type="LanguageType"
minOccurs="0" maxOccurs="unbounded"/>
<xs:sequence minOccurs="0">
<xs:element name="not-present" type="NotPresentAction"/>
<xs:element name="language" type="LanguageType"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:element name="otherwise" type="OtherwiseAction"
minOccurs="0"/>
</xs:sequence>
</xs:extension>
</xs:complexContent>
</xs:complexType>
<xs:element name="language-switch" type="LanguageSwitchType"
substitutionGroup="switch"/>
<xs:simpleType name="FreqType">
<xs:restriction base="xs:NMTOKEN">
<xs:pattern value="[s|S][e|E][c|C][o|O][n|N][d|D][l|L][y|Y]"/>
<xs:pattern value="[m|M][i|I][n|N][u|U][t|T][e|E][l|L][y|Y]"/>
<xs:pattern value="[h|H][o|O][u|U][r|R][l|L][y|Y]"/>
<xs:pattern value="[d|D][a|A][i|I][l|L][y|Y]"/>
<xs:pattern value="[w|W][e|E][e|E][k|K][l|L][y|Y]"/>
<xs:pattern value="[m|M][o|N][n|N][t|T][h|H][l|L][y|Y]"/>
<xs:pattern value="[y|Y][e|E][a|A][r|R][l|L][y|Y]"/>
</xs:restriction>
</xs:simpleType>
<xs:simpleType name="YearDayType">
<xs:union>
<xs:simpleType>
<xs:restriction base="xs:integer">
<xs:minInclusive value="-366"/>
<xs:maxInclusive value="-1"/>
</xs:restriction>
</xs:simpleType>
<xs:simpleType>
<xs:restriction base="xs:integer">
<xs:minInclusive value="1"/>
<xs:maxExclusive value="366"/>
</xs:restriction>
</xs:simpleType>
</xs:union>
</xs:simpleType>
<xs:simpleType name="DayType">
<xs:restriction base="xs:NMTOKEN">
<xs:pattern value="[m|M][o|O]"/>
<xs:pattern value="[t|T][u|U]"/>
<xs:pattern value="[w|W][e|E]"/>
<xs:pattern value="[t|T][h|H]"/>
<xs:pattern value="[f|F][r|R]"/>
<xs:pattern value="[s|S][a|A]"/>
<xs:pattern value="[s|S][u|U]"/>
</xs:restriction>
</xs:simpleType>
<xs:complexType name="TimeType">
<xs:annotation>
<xs:documentation>Exactly one of the two attributes "dtend" and
"duration" must occur. None of the attributes following
freq are meaningful unless freq appears.
</xs:documentation>
</xs:annotation>
<xs:group ref="Node"/>
<xs:attribute name="dtstart" type="xs:string" use="required">
<xs:annotation>
<xs:documentation>RFC 2445 DATE-TIME</xs:documentation>
</xs:annotation>
</xs:attribute>
<xs:attribute name="dtend" type="xs:string" use="optional">
<xs:annotation>
<xs:documentation>RFC 2445 DATE-TIME</xs:documentation>
</xs:annotation>
</xs:attribute>
<xs:attribute name="duration" type="xs:string" use="optional">
<xs:annotation>
<xs:documentation>RFC 2445 DURATION</xs:documentation>
</xs:annotation>
</xs:attribute>
<xs:attribute name="freq" type="FreqType" use="optional"/>
<xs:attribute name="interval" type="xs:positiveInteger"
default="1"/>
<xs:attribute name="until" type="xs:string" use="optional">
<xs:annotation>
<xs:documentation>RFC 2445 DATE-TIME</xs:documentation>
</xs:annotation>
</xs:attribute>
<xs:attribute name="count" type="xs:positiveInteger"
use="optional"/>
<xs:attribute name="bysecond" type="xs:string" use="optional">
<xs:annotation>
<xs:documentation>Comma-separated list of seconds within a
minute. Valid values are 0 to 59.</xs:documentation>
</xs:annotation>
</xs:attribute>
<xs:attribute name="byminute" type="xs:string" use="optional">
<xs:annotation>
<xs:documentation>Comma-separated list of minutes within an
hour. Valid values are 0 to 59.</xs:documentation>
</xs:annotation>
</xs:attribute>
<xs:attribute name="byhour" type="xs:string" use="optional">
<xs:annotation>
<xs:documentation>Comma-separated list of hours of the day.
Valid values are 0 to 23.</xs:documentation>
</xs:annotation>
</xs:attribute>
<xs:attribute name="byday" type="xs:string" use="optional">
<xs:annotation>
<xs:documentation>Comma-separated list of days of the week.
Valid values are "MO", "TU", "WE", "TH", "FR", "SA" and
"SU". These values are not case-sensitive. Each can be
preceded by a positive (+n) or negative (-n)
integer.</xs:documentation>
</xs:annotation>
</xs:attribute>
<xs:attribute name="bymonthday" type="xs:string" use="optional">
<xs:annotation>
<xs:documentation>Comma-separated list of days of the month.
Valid values are 1 to 31 or -31 to
-1.</xs:documentation>
</xs:annotation>
</xs:attribute>
<xs:attribute name="byyearday" type="xs:string" use="optional">
<xs:annotation>
<xs:documentation>Comma-separated list of days of the year.
Valid values are 1 to 366 or -366 to
-1.</xs:documentation>
</xs:annotation>
</xs:attribute>
<xs:attribute name="byweekno" type="xs:string" use="optional">
<xs:annotation>
<xs:documentation>Comma-separated list of ordinals specifying
weeks of the year. Valid values are 1 to 53 or -53 to
-1.</xs:documentation>
</xs:annotation>
</xs:attribute>
<xs:attribute name="bymonth" type="xs:string" use="optional">
<xs:annotation>
<xs:documentation>Comma-separated list of months of the year.
Valid values are 1 to 12.</xs:documentation>
</xs:annotation>
</xs:attribute>
<xs:attribute name="wkst" type="DayType" default="MO"/>
<xs:attribute name="bysetpos" type="YearDayType"/>
<xs:anyAttribute namespace="##any" processContents="lax"/>
</xs:complexType>
<xs:simpleType name="TZIDType">
<xs:restriction base="xs:string"/>
</xs:simpleType>
<xs:simpleType name="TZURLType">
<xs:restriction base="xs:anyURI"/>
</xs:simpleType>
<xs:complexType name="TimeSwitchType">
<xs:complexContent>
<xs:extension base="SwitchType">
<xs:sequence>
<xs:element name="time" type="TimeType" minOccurs="0"
maxOccurs="unbounded"/>
<xs:sequence minOccurs="0">
<xs:element name="not-present" type="NotPresentAction"/>
<xs:element name="time" type="TimeType" minOccurs="0"
maxOccurs="unbounded"/>
</xs:sequence>
<xs:element name="otherwise" type="OtherwiseAction"
minOccurs="0"/>
</xs:sequence>
<xs:attribute name="tzid" type="TZIDType"/>
<xs:attribute name="tzurl" type="TZURLType"/>
</xs:extension>
</xs:complexContent>
</xs:complexType>
<xs:element name="time-switch" type="TimeSwitchType"
substitutionGroup="switch"/>
<xs:simpleType name="PriorityValues">
<xs:restriction base="xs:NMTOKEN">
<xs:pattern
value="[e|E][m|M][e|E][r|R][g|G][e|E][n|N][c|C][y|Y]"/>
<xs:pattern value="[u|U][r|R][g|G][e|E][n|N][t|T]"/>
<xs:pattern value="[n|N][o|O][r|R][m|M][a|A][l|L]"/>
<xs:pattern
value="[n|N][o|O][n|N]-[u|U][r|R][g|G][e|E][n|N][t|T]"/>
</xs:restriction>
</xs:simpleType>
<xs:complexType name="PriorityType">
<xs:annotation>
<xs:documentation>Exactly one of the three attributes must
appear </xs:documentation>
</xs:annotation>
<xs:group ref="Node"/>
<xs:attribute name="less" type="PriorityValues"/>
<xs:attribute name="greater" type="PriorityValues"/>
<xs:attribute name="equal" type="xs:string">
<xs:annotation>
<xs:documentation>case-insensitive</xs:documentation>
</xs:annotation>
</xs:attribute>
<xs:anyAttribute namespace="##any" processContents="lax"/>
</xs:complexType>
<xs:complexType name="PrioritySwitchType">
<xs:complexContent>
<xs:extension base="SwitchType">
<xs:sequence>
<xs:element name="priority" type="PriorityType"
minOccurs="0" maxOccurs="unbounded"/>
<xs:sequence minOccurs="0">
<xs:element name="not-present" type="NotPresentAction"/>
<xs:element name="priority" type="PriorityType"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:element name="otherwise" type="OtherwiseAction"
minOccurs="0"/>
</xs:sequence>
</xs:extension>
</xs:complexContent>
</xs:complexType>
<xs:element name="priority-switch" type="PrioritySwitchType"
substitutionGroup="switch"/>
<xs:simpleType name="LocationPriorityType">
<xs:restriction base="xs:float">
<xs:minInclusive value="0.0"/>
<xs:maxInclusive value="1.0"/>
</xs:restriction>
</xs:simpleType>
<xs:complexType name="LocationType">
<xs:complexContent>
<xs:extension base="ModifierType">
<xs:group ref="Node"/>
<xs:attribute name="url" type="xs:anyURI" use="required"/>
<xs:attribute name="priority" type="LocationPriorityType"
use="optional" default="1.0"/>
<xs:attribute name="clear" type="YesNoType" default="no"/>
</xs:extension>
</xs:complexContent>
</xs:complexType>
<xs:complexType name="LookupType">
<xs:complexContent>
<xs:extension base="ModifierType">
<xs:all>
<xs:element name="success" minOccurs="0">
<xs:complexType>
<xs:group ref="Node"/>
</xs:complexType>
</xs:element>
<xs:element name="notfound" minOccurs="0">
<xs:complexType>
<xs:group ref="Node"/>
</xs:complexType>
</xs:element>
<xs:element name="failure" minOccurs="0">
<xs:complexType>
<xs:group ref="Node"/>
</xs:complexType>
</xs:element>
</xs:all>
<xs:attribute name="source" type="xs:string"
use="required"/>
<xs:attribute name="timeout" type="xs:positiveInteger"
default="30"/>
<xs:attribute name="clear" type="YesNoType" default="no"/>
</xs:extension>
</xs:complexContent>
</xs:complexType>
<xs:complexType name="RemoveLocationType">
<xs:complexContent>
<xs:extension base="ModifierType">
<xs:group ref="Node"/>
<xs:attribute name="location" type="xs:string"
use="optional"/>
</xs:extension>
</xs:complexContent>
</xs:complexType>
<xs:complexType name="LogAction">
<xs:complexContent>
<xs:extension base="ActionType">
<xs:group ref="Node"/>
<xs:attribute name="name" type="xs:string" use="optional"/>
<xs:attribute name="comment" type="xs:string"
use="optional"/>
</xs:extension>
</xs:complexContent>
</xs:complexType>
<xs:element name="log" type="LogAction"
substitutionGroup="action"/>
<xs:complexType name="IncomingType">
<xs:complexContent>
<xs:extension base="TopLevelActionType"/>
</xs:complexContent>
</xs:complexType>
<xs:element name="incoming" type="IncomingType"
substitutionGroup="toplevelaction"/>
<xs:complexType name="OutgoingType">
<xs:complexContent>
<xs:extension base="TopLevelActionType"/>
</xs:complexContent>
</xs:complexType>
<xs:element name="outgoing" type="OutgoingType"
substitutionGroup="toplevelaction"/>
<xs:complexType name="ProxyAction">
<xs:complexContent>
<xs:extension base="ActionType">
<xs:all>
<xs:element name="busy" minOccurs="0">
<xs:complexType>
<xs:group ref="Node"/>
</xs:complexType>
</xs:element>
<xs:element name="noanswer" minOccurs="0">
<xs:complexType>
<xs:group ref="Node"/>
</xs:complexType>
</xs:element>
<xs:element name="failure" minOccurs="0">
<xs:complexType>
<xs:group ref="Node"/>
</xs:complexType>
</xs:element>
<xs:element name="redirection" minOccurs="0">
<xs:complexType>
<xs:group ref="Node"/>
</xs:complexType>
</xs:element>
<xs:element name="default" minOccurs="0">
<xs:complexType>
<xs:group ref="Node"/>
</xs:complexType>
</xs:element>
</xs:all>
<xs:attribute name="timeout" type="xs:positiveInteger"
use="optional" default="20"/>
<xs:attribute name="recurse" type="YesNoType"
use="optional" default="yes"/>
<xs:attribute name="ordering" type="OrderingType"
use="optional" default="parallel"/>
</xs:extension>
</xs:complexContent>
</xs:complexType>
<xs:element name="proxy" type="ProxyAction"
substitutionGroup="action"/>
<xs:complexType name="RedirectAction">
<xs:complexContent>
<xs:extension base="ActionType">
<xs:attribute name="permanent" type="YesNoType"
default="no"/>
</xs:extension>
</xs:complexContent>
</xs:complexType>
<xs:element name="redirect" type="RedirectAction"
substitutionGroup="action"/>
<xs:complexType name="RejectAction">
<xs:complexContent>
<xs:extension base="ActionType">
<xs:attribute name="status" type="StatusType"
use="required"/>
<xs:attribute name="reason" type="xs:string"
use="optional"/>
</xs:extension>
</xs:complexContent>
</xs:complexType>
<xs:element name="reject" type="RejectAction"
substitutionGroup="action"/>
<xs:complexType name="MailAction">
<xs:complexContent>
<xs:extension base="ActionType">
<xs:group ref="Node"/>
<xs:attribute name="url" type="xs:anyURI" use="required"/>
</xs:extension>
</xs:complexContent>
</xs:complexType>
<xs:element name="mail" type="MailAction"
substitutionGroup="action"/>
<xs:complexType name="SubAction">
<xs:attribute name="ref" type="xs:string" use="required"/>
</xs:complexType>
<xs:complexType name="AncillaryType"/>
<xs:complexType name="SubactionType">
<xs:group ref="Node"/>
<xs:attribute name="id" use="required"/>
</xs:complexType>
<xs:complexType name="CPLType">
<xs:sequence>
<xs:element name="ancillary" type="AncillaryType" minOccurs="0"
maxOccurs="1"/>
<xs:element name="subaction" type="SubactionType" minOccurs="0"
maxOccurs="unbounded"/>
<xs:element ref="toplevelaction" minOccurs="0"
maxOccurs="unbounded">
<xs:annotation>
<xs:documentation>Any toplevel action MUST NOT appear more
than once.</xs:documentation>
</xs:annotation>
</xs:element>
</xs:sequence>
</xs:complexType>
<xs:element name="cpl" type="CPLType"/>
</xs:schema>
END
Normative References
引用文献
[1] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002.
[1] Rosenberg、J.、Schulzrinne、H.、Camarillo、G.、Johnston、A.、Peterson、J.、Sparks、R.、Handley、M。、およびE. Schooler、 "SIP：SESSION INIATIATION Protocol"、RFC 3261、2002年6月。
[2] Bray, T., Paoli, J., Sperberg-McQueen, C. M., Maler, E., and F. Yergeau, "Extensible Markup Language (XML) 1.0 (Third Edition)", W3C Recommendation REC-xml-20040204, World Wide Web Consortium (W3C), February 2004. Available at http://www.w3.org/XML/.
[2] Bray、T.、Paoli、J.、Sperberg-Mcqueen、C。M.、Maler、E。、およびF. Yergeau、「拡張可能なマークアップ言語（XML）1.0（第3版）」、W3C推奨REC-XML-20040204、World WideWebコンソーシアム（W3C）、2004年2月。http：//www.w3.org/xml/で入手可能。
[3] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[3] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[4] Hinden, R. and S. Deering, "Internet Protocol Version 6 (IPv6) Addressing Architecture", RFC 3513, April 2003.
[4] Hinden、R。and S. Deering、「インターネットプロトコルバージョン6（IPv6）アドレス指定アーキテクチャ」、RFC 3513、2003年4月。
[5] Davis, M. F. and M. Duerst, "Unicode Normalization Forms", Unicode Standard Annex #15, Unicode Consortium, April 2003. Revision 23; part of Unicode 4.0.0. Available at http://www.unicode.org/unicode/reports/tr15/.
[5] Davis、M。F。およびM. Duerst、「Unicode Normalization Forms」、Unicode Standard Annex＃15、Unicode Consortium、2003年4月23日。Unicode 4.0.0の一部。http://www.unicode.org/unicode/reports/tr15/で入手可能。
[6] Davis, M. F., "Case Mappings", Unicode Standard Annex #21, Unicode Consortium, March 2001. Revision 5; part of Unicode 3.2.0. Available at http://www.unicode.org/unicode/reports/tr21/.
[6] Davis、M。F.、「ケースマッピング」、Unicode Standard Annex＃21、Unicode Consortium、2001年3月。改訂5。Unicode 3.2.0の一部。http://www.unicode.org/unicode/reports/tr21/で入手できます。
[7] Alvestrand, H., "Tags for the Identification of Languages", BCP 47, RFC 3066, January 2001.
[7] Alvestrand、H。、「言語の識別のためのタグ」、BCP 47、RFC 3066、2001年1月。
[8] Dawson, F. and D. Stenerson, "Internet Calendaring and Scheduling Core Object Specification (iCalendar)", RFC 2445, November 1998.
[8] Dawson、F。and D. Stenerson、「インターネットカレンダーとスケジューリングコアオブジェクト仕様（ICALENDAR）」、RFC 2445、1998年11月。
[9] Eggert, P., "Sources for Time Zone and Daylight Saving Time Data". Available at http://www.twinsun.com/tz/tz-link.htm.
[9] Eggert、P。、「タイムゾーンと夏時間のデータのソース」。http://www.twinsun.com/tz/tz-link.htmで入手可能。
[10] Mealling, M. and R. Daniel, "URI Resolution Services Necessary for URN Resolution", RFC 2483, January 1999.
[10] Mealling、M。and R. Daniel、「URN解像度に必要なURI解像度サービス」、RFC 2483、1999年1月。
[11] Bray, T., Hollander, D., and A. Layman, "Namespaces in XML", W3C Recommendation REC-xml-names-19990114, World Wide Web Consortium (W3C), January 1999. Available at http://www.w3.org/TR/REC-xml-names/.
[11] Bray、T.、Hollander、D。、およびA. Layman、「XMLの名前空間」、W3C推奨REC-XML-NAMES-19990114、World Wide Web Consortium（W3C）、1999年1月。http：// wwwで入手可能。w3.org/tr/rec-xml-names/。
[12] Moats, R., "URN Syntax", RFC 2141, May 1997.
[12] Moats、R。、「urn構文」、RFC 2141、1997年5月。
[13] Moats, R., "A URN Namespace for IETF Documents", RFC 2648, August 1999.
[13] Moats、R。、「IETFドキュメント用のurnネームスペース」、RFC 2648、1999年8月。
[14] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, January 2004.
[14] Mealling、M。、「IETF XMLレジストリ」、BCP 81、RFC 3688、2004年1月。
[15] Murata, M., St.Laurent, S., and D. Kohn, "XML Media Types", RFC 3023, January 2001.
[15] Murata、M.、St.Laurent、S。、およびD. Kohn、「XML Media Types」、RFC 3023、2001年1月。
Informative References
参考引用
[16] International Telecommunication Union, "Packet-based multimedia communication systems", Recommendation H.323, Telecommunication Standardization Sector of ITU, Geneva, Switzerland, July 2003.
[16] 2003年7月。
[17] Lennox, J. and H. Schulzrinne, "Call Processing Language Framework and Requirements", RFC 2824, May 2000.
[17] Lennox、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 http://www.w3.org/TR/html4/.
[18] Raggett、D.、Le Hors、A。、およびI. Jacobs、「HTML 4.01仕様」、W3C推奨REC-HTML401-19991224、World Wide Webコンソーシアム（W3C）、1999年12月。.org/tr/html4/。
[19] ISO (International Organization for Standardization), "Information processing -- Text and office systems -- Standard Generalized Markup Language (SGML)", ISO Standard ISO 8879:1986(E), International Organization for Standardization, Geneva, Switzerland, October 1986.
[19] ISO（国際標準化機関）、「情報処理 - テキストおよびオフィスシステム - 標準的な一般化マークアップ言語（SGML）」、ISO標準ISO 8879：1986（e）、1986年10月、スイス、ジュネーブの国際標準化機関。
[20] ISO (International Organization for Standardization), "Data elements and interchange formats -- Information interchange -- Representation of dates and times", ISO Standard ISO 8601:2000(E), International Organization for Standardization, Geneva, Switzerland, December 2000.
[20] ISO（国際標準化機関）、「データ要素と交換形式 - 情報交換 - 日付と時間の表現」、ISO標準ISO 8601：2000（e）、国際標準化機関、ジュネーブ、スイス、2000年12月。
[21] DeRose, S., Maler, E., Orchard, D., and B. Trafford, "XML Linking Language (XLink) Version 1.0", W3C Recommendation REC-xlink-20010627, World Wide Web Consortium (W3C), June 2001. Available at http://www.w3.org/TR/xlink/.
[21] Derose、S.、Maler、E.、Orchard、D。、およびB. Trafford、「XML Linking Language（Xlink）バージョン1.0」、W3C推奨REC-XLINK-20010627、World Wide Web Consortium（W3C）、2001年6月。http://www.w3.org/tr/xlink/で入手可能。
[22] Showalter, T., "Sieve: A Mail Filtering Language", RFC 3028, January 2001.
[22] Showalter、T。、「Sieve：A Mail Filtering Language」、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] 国際電気通信ユニオン、「デジタルサブスクライバーシグナルシステムNo. 1（DSS 1） - ISDNユーザーネットワークインターフェイスレイヤー3基本コールコントロールの仕様」、推奨Q.931、国際電気通信ユニオン、ジュネーブ、スイス、1993年3月。
[24] Levin, O., "H.323 Uniform Resource Locator (URL) Scheme Registration", RFC 3508, April 2003.
[24] Levin、O。、「H.323ユニフォームリソースロケーター（URL）スキーム登録」、RFC 3508、2003年4月。
Authors' Addresses
著者のアドレス
Jonathan Lennox Dept. of Computer Science Columbia University 1214 Amsterdam Avenue, MC 0401 New York, NY 10027 USA
コンピュータサイエンスコロンビア大学のジョナサンレノックス部1214アムステルダムアベニュー、MC 0401ニューヨーク、ニューヨーク10027 USA
EMail: lennox@cs.columbia.edu
Xiaotao Wu Dept. of Computer Science Columbia University 1214 Amsterdam Avenue, MC 0401 New York, NY 10027 USA
Xiaotao Wu Dept. of Computer Science Columbia University 1214 Amsterdam Avenue、MC 0401 New York、NY 10027 USA
EMail: xiaotaow@cs.columbia.edu
Henning Schulzrinne Dept. of Computer Science Columbia University 1214 Amsterdam Avenue, MC 0401 New York, NY 10027 USA
コンピューターサイエンスコロンビア大学のヘニングシュルツリン部1214アムステルダムアベニュー、MC 0401ニューヨーク、ニューヨーク10027 USA
EMail: schulzrinne@cs.columbia.edu
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2004).
著作権（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に含まれる権利、ライセンス、および制限の対象となり、そこに記載されている場合を除き、著者はすべての権利を保持しています。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供されています。また、貢献者、彼/彼女が代表する組織（もしあれば）が後援する組織、インターネット協会とインターネット工学タスクフォースは、すべての保証、明示的または明示的、またはすべての保証を否認します。本書の情報の使用が、商品性または特定の目的に対する適合性の権利または黙示的な保証を侵害しないという保証を含むがこれらに限定されないことを含む。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the IETF's procedures with respect to rights in IETF Documents can be found in BCP 78 and BCP 79.
IETFは、知的財産権またはその他の権利の有効性または範囲に関して、本書に記載されている技術の実装または使用、またはそのような権利に基づくライセンスに基づくライセンスの範囲に関連すると主張される可能性のある他の権利に関しては、立場を取得しません。利用可能になります。また、そのような権利を特定するために独立した努力をしたことも表明していません。IETFドキュメントの権利に関するIETFの手順に関する情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得するための試みの結果を取得できます。http://www.ietf.org/iprのIETFオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、関心のある当事者に、著作権、特許、または特許出願、またはこの基準を実装するために必要なテクノロジーをカバーする可能性のあるその他の独自の権利を注意深く招待します。ietf-ipr@ietf.orgのIETFへの情報をお問い合わせください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFCエディター機能の資金は現在、インターネット協会によって提供されています。