Network Working Group J. Lennox
Request for Comments: 3880 X. Wu
Category: Standards Track H. Schulzrinne
Columbia University
October 2004
Call Processing Language (CPL):
A Language for User Control of Internet Telephony Services
Status of this Memo
このメモの位置付け
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
この文書は、インターネットコミュニティのためのインターネット標準トラックプロトコルを指定し、改善のための議論と提案を要求します。このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」（STD 1）の最新版を参照してください。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2004).
著作権（C）インターネット協会（2004）。
Abstract
抽象
This document defines the Call Processing Language (CPL), a language to describe and control Internet telephony services. It is designed to be implementable on either network servers or user agents. It is meant to be simple, extensible, easily edited by graphical clients, and independent of operating system or signalling protocol. It is suitable for running on a server where users may not be allowed to execute arbitrary programs, as it has no variables, loops, or ability to run external programs.
この文書では、呼処理言語（CPL）、インターネット電話サービスを記述し、制御するための言語を定義します。ネットワークサーバーやユーザーエージェントのいずれかで実施可能となるように設計されています。簡単、容易にグラフィカル・クライアントによって編集された拡張可能、およびオペレーティングシステムまたはシグナリングプロトコルとは無関係であることを意味します。それは何の変数、ループ、または外部プログラムを実行する機能を持っていないとして、ユーザーは、任意のプログラムを実行することは許されないことがあり、サーバー上で実行されているに適しています。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Conventions of This Document. . . . . . . . . . . . . . 4
2. Structure of CPL Scripts . . . . . . . . . . . . . . . . . . . 4
2.1. High-level Structure. . . . . . . . . . . . . . . . . . 4
2.2. Abstract Structure of a Call Processing Action. . . . . 5
2.3. Location Model. . . . . . . . . . . . . . . . . . . . . 6
2.4. XML Structure . . . . . . . . . . . . . . . . . . . . . 6
3. Script Structure: Overview . . . . . . . . . . . . . . . . . . 7
4. Switches . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
4.1. Address Switches. . . . . . . . . . . . . . . . . . . . 9
4.1.1. Usage of "address-switch" with SIP. . . . . . . 11
4.2. String Switches . . . . . . . . . . . . . . . . . . . . 12
4.2.1. Usage of "string-switch" with SIP . . . . . . . 13
4.3. Language Switches . . . . . . . . . . . . . . . . . . . 14
4.3.1. Usage of "language-switch" with SIP . . . . . . 14
4.4. Time Switches . . . . . . . . . . . . . . . . . . . . . 15
4.4.1. iCalendar differences and implementation
issues. . . . . . . . . . . . . . . . . . . . . 20
4.5. Priority Switches . . . . . . . . . . . . . . . . . . . 21
4.5.1. Usage of "priority-switch" with SIP . . . . . . 22
5. Location Modifiers . . . . . . . . . . . . . . . . . . . . . . 22
5.1. Explicit Location . . . . . . . . . . . . . . . . . . . 23
5.1.1. Usage of "location" with SIP. . . . . . . . . . 23
5.2. Location Lookup . . . . . . . . . . . . . . . . . . . . 24
5.2.1. Usage of "lookup" with SIP. . . . . . . . . . . 25
5.3. Location Removal. . . . . . . . . . . . . . . . . . . . 25
5.3.1. Usage of "remove-location" with SIP . . . . . . 26
6. Signalling Operations. . . . . . . . . . . . . . . . . . . . . 26
6.1. Proxy . . . . . . . . . . . . . . . . . . . . . . . . . 26
6.1.1. Usage of "proxy" with SIP . . . . . . . . . . . 29
6.2. Redirect. . . . . . . . . . . . . . . . . . . . . . . . 29
6.2.1. Usage of "redirect" with SIP. . . . . . . . . . 30
6.3. Reject. . . . . . . . . . . . . . . . . . . . . . . . . 30
6.3.1. Usage of "reject" with SIP. . . . . . . . . . . 30
7. Non-signalling Operations. . . . . . . . . . . . . . . . . . . 31
7.1. Mail. . . . . . . . . . . . . . . . . . . . . . . . . . 31
7.1.1. Suggested Content of Mailed Information . . . . 32
7.2. Log . . . . . . . . . . . . . . . . . . . . . . . . . . 32
8. Subactions . . . . . . . . . . . . . . . . . . . . . . . . . . 33
9. Ancillary Information. . . . . . . . . . . . . . . . . . . . . 34
10. Default Behavior . . . . . . . . . . . . . . . . . . . . . . . 35
11. CPL Extensions . . . . . . . . . . . . . . . . . . . . . . . . 35
12. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
12.1. Example: Call Redirect Unconditional. . . . . . . . . . 37
12.2. Example: Call Forward Busy/No Answer. . . . . . . . . . 38
12.3. Example: Call Forward: Redirect and Default . . . . . . 39
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]及び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.
この文書では、キーワード "MUST"、 "MUST NOT"、 "REQUIRED"、 "NOT SHALL"、 "推奨"、 "すべきではない" "べきである" "ないものと"、 "MAY"、および "オプション" BCP 14、RFC 2119に記載されているように、[3]に解釈されるべきであり、対応CPL実装の要求レベルを示します。
Some paragraphs are indented, like this; they give motivations of design choices, advice to implementors, or thoughts on future development of or extensions to CPL. They are not essential to the specification of the language, and are non-normative.
いくつかの段落では、このように、インデントされ;彼らは設計上の選択、実装者へのアドバイス、または将来の開発や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が設計されています。ノードは、単一のルートノードから開始して、ツリーに配置されています。ノードの出力は、追加のノードに接続されています。アクションが実行されると、アクションの最上位ノードによって記述アクションまたは決定が行われます。そのノードの結果に基づいて、サーバは、ノードの出力のいずれかを、以下、それが指す後続ノードが実行されます。指定しない出力を有するノードに到達するまで、このプロセスが継続します。グラフが非環式であるため、ノードの有界かつ予測可能な数が訪問された後、これが発生します。
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のために必要な情報の一つは、ノードパラメータとして与えられていません。代わりに、場所のこのセットは、処理アクション（およびそのサブアクション）の実行を通して暗黙のグローバル変数として格納されます。これは、（言語を理解するのシンプルさと取り扱いやすさを損なう可能性）このような操作のための一般的な言語サポートを必要とせず、等ろ過し、位置が外部ソースから取得することが可能になる、と。追加の特定の操作は、検索、またはフィルタ位置セットは、セクション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).
CPL内の両方のノードと出力がXMLタグによって表される図1にCPLスクリプトのグラフィカル表現に対応するXML文書については、図2を参照されたいです。パラメータは、XMLタグの属性によって表されます。典型的には、（いくつかの例外を除いて：セクション5.1、5.3、7.1、および7.2を参照）、ノードタグは出力タグを含み、その逆。
The connection between the output of a node and another node is represented by enclosing the tag representing the pointed-to node inside the tag for the outer node's output. Convergence (several outputs pointing to a single node) is represented by subactions, discussed further in Section 8.
ノードの出力と別のノードとの間の接続を表すタグを囲んで表される尖ったから外側ノードの出力のためのタグの内部ノード。収束は、（複数の出力を単一のノードを指す）、サブアクションで表されるセクション8で詳しく説明されています。
The higher-level structure of a CPL script is represented by tags corresponding to each piece of ancillary information, subactions, and top-level actions, in order. This higher-level information is all enclosed in a special tag "cpl", the outermost tag of the XML document.
ためにCPLスクリプトの高レベルの構造は、補助情報の各部分に対応するタグ、サブアクション、およびトップレベルのアクションで表されます。この高いレベルの情報は、すべての特殊タグ「CPL」、XML文書の最も外側のタグで囲まれています。
A complete XML Schema for CPL is provided in Appendix C. The remainder of the main sections of this document describe the semantics of CPL, while giving its syntax informally. For the formal syntax, please see the appendix.
CPLのための完全なXMLスキーマは、非公式にその構文を与えながら、CPLの意味を説明し、付録C.で、この文書の主なセクションの残りの部分を提供します。正式な構文については、付録を参照してください。
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>
<？xml version = "1.0" エンコード= "UTF-8"？> <CPLののxmlns = "壷：IETF：のparams：XML：NS：CPL" のxmlns：XSI = "http://www.w3.org/2001 / XMLスキーマ・インスタンス」のxsi：のschemaLocation = "URN：IETF：paramsは：XML：NS：> jones@voicemail.example.com "：CPLは "> <サブアクションID =" ボイスメール"> <場所のURL =" SIPをcpl.xsd <リダイレクト/> </場所> </サブアクション> <着信> <アドレス・スイッチ・フィールド= "オリジン" サブフィールド= "ホスト"> <場所のURL = "SIP < "example.com"=サブドメイン-のアドレス>：ジョーンズ@ example.com "> <プロキシタイムアウト=" 10 "> <忙しい> <サブREF =" ボイスメール」/> </忙しい> <noanswer> <サブREF = "ボイスメール" /> </ noanswer> <失敗> <サブREF = "ボイスメール" /> </失敗> </プロキシ> </場所>
</address> <otherwise> <sub ref="voicemail" /> </otherwise> </address-switch> </incoming> </cpl>
</アドレス> <そうでない> <サブREF = "ボイスメール" /> </さもなければ> </アドレススイッチ> </着信> </ CPL>
Figure 2: Sample CPL Script: XML Version
図2：XMLバージョン：CPLスクリプトの例
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.
他の条件が一致しなかった場合、それが存在する場合、最後に指定した出力でなければならない「そう」の出力は、一致しました。
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』、または 『表示』（も： 『パスワード』と 『エイリアス型』）
Output: "address" Parameters: "is" Exact match "contains" Substring match (for "display" only) "subdomain-of" Sub-domain match (for "host", "tel")
出力：「アドレス」パラメータ：完全一致は「サブドメイン-の」サブドメインの一致（「ホスト」、「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つのノードのパラメータを持っています。必須「フィールド」パラメータは、スクリプトは、スイッチのために考慮されるべきアドレスを指定することができます：いずれかのコールの発信元アドレス（フィールド「起源」）、現在の宛先アドレス（フィールド「宛先」）、または元の宛先（フィールド「オリジナルの先」）、それ以前の転送が呼び出された前にコールが持っていた先。サーバーは、追加のフィールドの値を定義することができます。
The optional "subfield" specifies which part of the address is to be considered. The possible subfield values are: "address-type", "user", "host", "port", "tel", and "display". Additional subfield values MAY be defined for protocol-specific values. (The subfield "password" is defined for SIP in Section 4.1.1; the subfield "alias-type" is defined for H.323 in Appendix B.1.) If no subfield is
オプションの「サブフィールド」を指定したアドレスの一部を考慮する必要があります。可能なサブフィールド値は「アドレス型」、「ユーザ」、「ホスト」、「ポート」、「TEL」、および「表示」。追加のサブフィールドの値は、プロトコル固有の値に対して定義されてもよいです。 （サブフィールド「パスワード」は、セクション4.1.1でSIPのために定義され、サブフィールド「別名型は、」付録B.1にH.323のために定義されている。）は、サブフィールドがない場合
specified, the "entire" address is matched; the precise meaning of this is defined for each underlying signalling protocol. Servers MAY define additional subfield values.
指定された、「全体」のアドレスが一致しています。これの正確な意味は、それぞれの基礎となるシグナリングプロトコルのために定義されています。サーバーは、追加のサブフィールドの値を定義することができます。
The subfields are defined as follows:
次のようにサブフィールドが定義されています。
address-type: This indicates the type of the underlying address, i.e., the URI scheme, if the address can be represented by a URI. The types specifically discussed by this document are "sip", "tel", and "h323". The address type is not case-sensitive. It has a value for all defined address types.
アドレス型：アドレスはURIで表すことができる場合、これは、下層のアドレス、すなわち、URIスキームのタイプを示します。特にこの文書で述べたタイプは「一口」、「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解決を行いません。 IPv4アドレスは、IPv6アドレスがV4-で-v6の埋め込みであっても、IPv6アドレスに等しいことはありません。このサブフィールドは、大文字と小文字が区別されず、存在しなくてもよいです。
For host names only, subdomain matching is supported with
the "subdomain-of" match operator. The "subdomain-of"
operator ignores leading dots in the hostname or match
pattern, if any.
port: This subfield indicates the TCP or UDP port number of the address, numerically, in decimal format. It is not case sensitive, as it MUST only contain decimal digits. Leading zeros are ignored.
ポート：このサブフィールドは、10進形式で、数値的に、アドレスの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.
表示：このサブフィールドは、「表示名」またはアドレスに対応するユーザに見える名前を示します。これは、Unicode文字列であり、セクション4.2で説明大文字と小文字を区別しないアルゴリズムを使用して整合されます。 「を含む」演算子は、それに適用することができます。これは、存在しなくてもよいです。
For any completely unknown subfield, the server MAY reject the script at the time it is submitted with an indication of the problem; if a script with an unknown subfield is executed, the server MUST consider the "not-present" output to be the valid one.
任意の完全に未知のサブフィールドの場合、サーバーは、それが問題の兆候で提出された時点でスクリプトを拒否するかもしれません。未知のサブフィールドでスクリプトが実行された場合、サーバは「-存在しない」出力は有効なものであることを考慮しなければなりません。
The "address" output tag may take exactly one of three possible parameters, indicating the kind of matching allowed.
「アドレス」出力タグが許可マッチングの種類を示す、ちょうど3つの可能なパラメータのいずれかをとることができます。
is: An output with this match operator is followed if the subfield being matched in the "address-switch" exactly matches the argument of the operator. It may be used for any subfield, or for the entire address if no subfield was specified.
ある：「アドレス・スイッチ」で一致しているサブフィールドが正確に演算子の引数に一致する場合、このマッチ演算子と出力が続いています。いかなるサブフィールドが指定されていない場合は、任意のサブフィールドのための、またはアドレス全体のために使用することができます。
subdomain-of: This match operator applies only for the subfields "host" and "tel". In the former case, it matches if the hostname being matched is a subdomain of the domain given in the argument of the match operator; thus, subdomain-of="example.com" would match the hostnames "example.com", "research.example.com", and "zaphod.sales.internal.example.com". IP addresses may be given as arguments to this operator; however, they only match exactly. In the case of the "tel" subfield, the output matches if the telephone number being matched has a prefix that matches the argument of the match operator; subdomain-of="1212555" would match the telephone number "1 212 555 1212."
サブドメイン-の：このマッチ演算子は、サブフィールド「ホスト」と「TEL」に適用されます。一致しているホスト名が一致演算の引数で指定されたドメインのサブドメインである場合、前者の場合には、一致します。従って、 "example.com" =-のサブドメインがホスト名と一致するであろう "example.com"、 "research.example.com"、および "zaphod.sales.internal.example.com"。 IPアドレスは、この演算子の引数として与えられることができます。しかし、彼らは唯一の完全に一致します。一致している電話番号が一致オペレータの引数と一致する接頭辞を有する場合、「TEL」サブフィールドの場合には、出力が一致します。 =「1212555」-のサブドメインは、電話番号「1 212 555 1212」に一致します
contains: This match operator applies only for the subfield "display". The output matches if the display name being matched contains the argument of the match as a substring.
含まれています。このマッチ演算子のみをサブフィールド「表示」に適用されます。一致している表示名が列として試合の引数が含まれている場合は出力が一致しました。
For SIP, the "origin" address corresponds to the address in the "From" header, "destination" corresponds to the "Request-URI", and "original-destination" corresponds to the "To" header.
SIPは、「原点」のアドレスが「From」ヘッダ内のアドレスに対応し、「宛先」は「リクエスト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」サブフィールドであります「ユーザ= phone」パラメータがURIに指定された場合、またはサーバが他の電話番号等のユーザ部分を認識するように構成されている場合、視覚セパレータを剥離して、URIの「ユーザ」部分であると定義されます。追加のサブフィールド、「パスワード」は、SIP URIの「パスワード」要素に対応するように定義され、大文字と小文字が区別されています。しかし、このフィールドの使用は、一般的なセキュリティ上の理由から推奨されません。
For tel URLs, the "tel" and "user" subfields are the subscriber name; in the former case, visual separators are stripped. The "host" and "port" subfields are both not present.
TELのURLについては、「TEL」と「ユーザー」のサブフィールドは、加入者名です。前者の場合には、視覚的なセパレータは削除されます。 「ホスト」と「ポート」サブフィールドは両方存在しません。
For h323 URLs, subfields MAY be set according to the scheme described in Appendix B.
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の一部です。一致は、標準のSIP URIマッチング規則が使用されている「です」。 「を含む」一致のために、URIがそのまま使用されます。
String switches allow a CPL script to make decisions based on free-form strings present in a call request. They are summarized in Figure 5.
文字列のスイッチは、CPLスクリプトがコール要求に存在する自由形式の文字列に基づいて意思決定を行うことができます。これらは、図5に要約されています。
Node: "string-switch"
Outputs: "string" Specific string to match
Parameters: "field" "subject", "organization",
"user-agent", or "display"
Output: "string" Parameters: "is" Exact match "contains" Substring match
出力：「文字列」パラメータ：完全一致は、サブストリングの一致「が含まれている」「されます」
Figure 5: Syntax of the "string-switch" node
図5：「文字列スイッチ」ノードのシンタックス
String switches have one node parameter: "field". The mandatory "field" parameter specifies which string is to be matched.
「フィールド」：文字列のスイッチは、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つのフィールドが定義されており、以下のとおりです。これらのフィールドのそれぞれの値が定義されていない他の構造を持つ自由形式のUnicode文字列です。
subject: The subject of the call.
件名：呼び出しの対象。
organization: The organization of the originator of the call.
組織：コールの発信者の組織化。
user-agent: The name of the program or device with which the call request was made.
ユーザーエージェント：コール要求が行われたとのプログラムまたはデバイスの名前。
display: Free-form text associated with the call, intended to be displayed to the recipient, with no other semantics defined by the signalling protocol.
表示：シグナリングプロトコルによって定義されていない他の意味で、受信者に表示されることを意図呼び出し、関連付けられた自由形式のテキスト。
Strings are matched as case-insensitive Unicode strings, in the following manner. First, strings are canonicalized to the "Compatibility Composition" (KC) form, as specified in Unicode Standard Annex #15 [5]. Then, strings are compared using locale-insensitive caseless mapping, as specified in Unicode Standard Annex #21 [6].
文字列は次のようにして、大文字と小文字を区別しないUnicode文字列として一致しています。 [5] Unicode規格付属書＃15で指定されるように、まず、文字列は、「互換性組成物」（KC）を形成するために正規化されます。次に、文字列は＃21附属書ユニコード規格に指定されている[6]、ロケール非感受性ケースレスマッピングを使用して比較されます。
Code to perform the first step, in Java and Perl, is available; see the links from Annex 5 of UAX 15 [5]. The case-insensitive string comparison in the Java standard class libraries already performs the second step; other Unicode-aware libraries should be similar.
最初のステップを実行するためのコードは、JavaやPerlで、利用可能です。 UAX 15の附属書5からのリンクを参照してください[5]。 Javaの標準クラスライブラリで大文字と小文字を区別しない文字列比較は、既に第2工程を行います。他のUnicode対応ライブラリが類似していなければなりません。
The output tag of string matching is named "string", and has a mandatory argument, one of "is" or "contains", indicating whole-string match or substring match, respectively.
文字列照合の出力タグは、「文字列」と名付けられ、それぞれ、全体の文字列一致またはサブストリングの一致を示す必須引数、又は「含有する」、「さ」のいずれかを有しています。
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つのパラメータを取ります。 [7] RFC 3066で定義されているパラメータの値は、言語タグです。 RFC 3066 CPLサーバチェック要求で指定された言語範囲に対してスクリプトで指定された各言語のタグで定義されるように、発信者はまた、言語範囲のセットを指定してもよいです。
See RFC 3066 for the details of how language-ranges match language-tags. Briefly, a language-range matches a language-tag if it exactly equals the tag, or if it exactly equals a prefix of the tag such that the first character following the prefix is "-".
言語範囲は、言語タグと一致する方法の詳細については、RFC 3066を参照してください。 「 - 」それはまさにタグに等しい、またはそれは正確にタグの接頭辞と等しい場合に接頭辞に続く最初の文字があるような場合には簡単に言えば、言語の範囲は、言語タグに一致します。
If the caller specified the special language-range "*", it is ignored for the purpose of matching. Languages with a "q" value of 0 are also ignored.
呼び出し側が特別な言語範囲「*」を指定した場合、それはマッチングの目的のために無視されます。 0の「Q」の値を持つ言語も無視されます。
This switch MAY be not-present.
このスイッチは、存在しないかもしれ。
The language-ranges for the "language-switch" switch are obtained from the SIP "Accept-Language" header field. The switch is not-present if the initial SIP request did not contain this header field.
「言語スイッチ」スイッチの言語範囲はSIP「受け入れ言語」ヘッダフィールドから得られます。初期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の最初のマッチの意味の「受け入れ言語」ヘッダフィールドの0以外の「Q」の値は無視されることに留意されたいです。
Time switches allow a CPL script to make decisions based on the time and/or date the script is being executed. They are summarized in Figure 7.
タイムスイッチは、CPLスクリプトは、時間および/または日付スクリプトが実行されているに基づいて意思決定を行うことができます。これらは、図7に要約されています。
Time switches are independent of the underlying signalling protocol.
タイムスイッチは、基礎となるシグナリングプロトコルとは無関係です。
Node: "time-switch" Outputs: "time" Specific time to match Parameters: "tzid" RFC 2445 Time Zone Identifier "tzurl" RFC 2445 Time Zone URL
ノード：「タイムスイッチ」出力：パラメータと一致するように、「時間」、特定の時間：「TZID」RFC 2445タイムゾーン識別子「tzurl」RFC 2445タイムゾーンのURL
Output: "time" Parameters: "dtstart" Start of interval (RFC 2445 DATE-TIME) "dtend" End of interval (RFC 2445 DATE-TIME) "duration" Length of interval (RFC 2445 DURATION) "freq" Frequency of recurrence ("secondly", "minutely", "hourly", "daily", "weekly", "monthly", or "yearly") "interval" How often the recurrence repeats "until" Bound of recurrence (RFC 2445 DATE-TIME) "count" Number of occurrences of recurrence "bysecond" List of seconds within a minute "byminute" List of minutes within an hour "byhour" List of hours of the day "byday" List of days of the week "bymonthday" List of days of the month "byyearday" List of days of the year "byweekno" List of weeks of the year "bymonth" List of months of the year "wkst" First day of the work week "bysetpos" List of values within set of events specified
出力： "時間" パラメータ： "DTSTART" スタート間隔の（RFC 2445 DATE-TIME）の間隔（RFC 2445 DATE-TIME） "期間" 間隔の長さ（RFC 2445 DURATION）の "DTEND" 終了 "FREQ" 周波数再発の（「第二」、「細かく」、「時間給」、「毎日」、「毎週」「毎月」、または「毎年」）再発のバウンド「まで」「間隔」どのくらいの頻度で再発を繰り返す（RFC 2445 DATE-TIME ）「カウント」再発の発生数「BYSECOND」分の分「BYMINUTE」リスト内の秒の一覧時間以内、一日の時間の「BYHOUR」リストの週の「BYMONTHDAY」リストの日のリスト「BYDAY」年「のWkst」の数ヶ月のリスト「BYMONTH」年の週のリスト「BYWEEKNO」年の日の月の日「byyearday」リストイベントのセット内の値の作業週「BYSETPOS」リストの最初の日指定されました
Figure 7: Syntax of the "time-switch" node
図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].
タイムスイッチはRFC 2445、インターネットカレンダーおよびスケジューリング中核オブジェクト仕様（iCalendarのCOS）における時間の繰り返し間隔の仕様に密接に基づいている[8]。
This allows CPL scripts to be generated automatically from calendar books. It also allows us to re-use the extensive existing work specifying time intervals.
これは、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.
「タイムスイッチ」タグは、RFC 2445（それぞれ、セクション4.8.3.1および4.8.3.5）で定義され、どちらも2つのオプションのパラメータ、「TZID」及び「tzurl」をとります。 「TZIDは、」タイムゾーン定義が参照される識別ラベルです。それはスラッシュ（斜線）で始まる場合、それはTO-定義するグローバルタイムゾーンのレジストリを参照します。それ以外の場合は、サーバーでローカルに定義されています。 「tzurl」はタイムゾーンのための最新のVTIMEZONE定義を取得するためのネットワーク上の場所を与えます。
While "tzid" labels that do not begin with a forward slash are locally defined, it is RECOMMENDED that servers support at least the naming scheme used by the Olson Time Zone database [9]. Examples of timezone databases that use the Olson scheme are the zoneinfo files on most Unix-like systems, and the standard Java TimeZone class.
スラッシュで始まらない「TZID」ラベルがローカルに定義されているが、サーバが少なくともオルソンタイムゾーンデータベース[9]で使用される命名規則をサポートすることが推奨されます。オルソン方式を用いるタイムゾーンデータベースの例は、ほとんどのUnixライクなシステムにzoneinfoのファイル、および標準のJava TimeZoneのクラスです。
Servers SHOULD resolve "tzid" and "tzurl" references to time zone definitions at the time the script is uploaded. They MAY periodically refresh these resolutions to obtain the most up-to-date definition of a time zone. If a "tzurl" becomes invalid, servers SHOULD remember the most recent valid data retrieved from the URL.
サーバは、スクリプトがアップロードされた時点でのタイムゾーンの定義に「TZID」と「tzurl」の参照を解決する必要があります。彼らは定期的にタイムゾーンの最新の定義を取得するためにこれらの解像度を更新するかもしれません。 「tzurl」は無効になると、サーバーは、URLから取得した最新の有効なデータを覚えておいてください。
If a script is uploaded with a "tzid" and "tzurl" which the CPL server does not recognize or cannot resolve, it SHOULD diagnose and reject this at script upload time. If neither "tzid" nor "tzurl" are present, all non-UTC times within this time switch should be interpreted as being "floating" times, i.e., that they are specified in the local timezone of the CPL server.
スクリプトはCPLサーバーが認識しないか、解決できない「TZID」と「tzurl」でアップロードされている場合は、それが診断し、スクリプトのアップロード時にこれを拒否すべきです。 「TZID」や「tzurl」どちらがすべての非UTC時間は、存在する場合、この時間内にスイッチは、それらがCPLサーバーのローカルタイムゾーンに指定されていることを、「フローティング」回、すなわちあるものとして解釈されるべきです。
Because of daylight-savings-time changes over the course of a year, it is necessary to specify time switches in a given timezone. UTC offsets are not sufficient, or a time-of-day routing rule which held between 9 am and 5 pm in the eastern United States would start holding between 8 am and 4 pm at the end of October.
年間を通じて夏時間時間の変化のため、指定されたタイムゾーンの時刻スイッチを指定する必要があります。 UTCオフセットは十分ではない、または米国東部で午前9時から午後5時までの間で開催されたtime-of-dayルーティングルールは、10月の終わりに午前8時と午後4時間保持を開始するでしょう。
Authors of CPL servers should be careful to handle correctly the intervals when local time is discontinuous, at the beginning or end of daylight-savings time. Note especially that some times may occur more than once when clocks are set back. The algorithm in Appendix A is believed to handle this correctly.
現地時間は夏時間の開始または終了時に、不連続であるとき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」、および「DTEND」または「期間」の正確に一つの、それぞれ、終了時刻または期間の長さを指定します。彼らは、2つの必須パラメータがあります。 RFC 2445のセクション4.3.5で指定されるように "DTSTART" と "DTEND" パラメータは、のiCalendar COS DATE-TIME値としてフォーマットされている[8]。タイムゾーンがトップレベル「時間スイッチ」タグで指定されているので、わずか1又は2（フローティングまたはUTC時間）を形成して使用することができます。 RFC 2445のセクション4.3.6で指定されるように、「継続時間」パラメータは、iCalendarのCOS期間パラメータとして与えられている日時および期間の構文の両方はISO 8601からの対応する構文[20]のサブセットです。
For a recurring interval, the "duration" parameter MUST be small enough such that subsequent intervals do not overlap. For non-recurring intervals, durations of any positive length are permitted. Zero-length and negative-length durations are not allowed.
定期的な間隔のために、「継続時間」パラメータは、後続の間隔が重複しないように十分に小さくなければなりません。非定期的な間隔で、任意の正の長さの期間が許可されます。長さがゼロと負の長さの期間が許可されていません。
If no other parameters are specified, a time node indicates only a single period of time. More complicated sets of period intervals are constructed as recurrences. A recurrence is specified by including the "freq" parameter, which indicates the type of recurrence rule. Parameters other than "dtstart", "dtend", and "duration" SHOULD NOT be specified unless "freq" is present, though CPL servers SHOULD accept scripts with such parameters present, and ignore the other parameters.
他のパラメータが指定されていない場合、タイムノードは時間の単一期間を示します。期間間隔のより複雑なセットが再発として構成されています。再発は再発ルールの種類を示す「FREQ」パラメータを含むことによって特定されます。 「DTSTART」、「DTEND」、および「期間」以外のパラメータは、CPLサーバが存在し、このようなパラメータを使用してスクリプトを受け入れ、および他のパラメータを無視すべきであるにもかかわらず、「FREQ」は、存在しない限り、指定しないでください。
The "freq" parameter takes one of the following values: "secondly", to specify repeating periods based on an interval of a second or more, "minutely", to specify repeating periods based on an interval of a minute or more, "hourly", to specify repeating periods based on an interval of an hour or more, "daily", to specify repeating periods based on an interval of a day or more, "weekly", to specify repeating periods based on an interval of a week or more, "monthly", to specify repeating periods based on an interval of a month or more, and "yearly", to specify repeating periods based on an interval of a year or more. These values are not case-sensitive.
「FREQ」パラメータは、次のいずれかの値をとり、「第二」、毎時」、分以上の間隔に基づいて、繰り返し期間を指定するために、秒以上、「微細」の間隔に基づいて、繰り返し期間を指定します」、繰り返し時間の間隔に基づいて期間以上を指定するには、 『週の間隔に基づいて、繰り返し期間を指定するには、『毎週』、一日以上の間隔に基づいて、繰り返し期間を指定するには、』毎日または年以上の間隔に基づいて、繰り返し期間を指定するには、月以上の間隔に基づいて、繰り返し期間を指定し、「毎年」ことが、より、「毎月」。これらの値は、大文字と小文字は区別されません。
The "interval" parameter contains a positive integer representing how often the recurrence rule repeats. The default value is "1", meaning every second for a "secondly" rule, every minute for a "minutely" rule, every hour for an "hourly" rule, every day for a "daily" rule, every week for a "weekly" rule, every month for a "monthly" rule, and every year for a "yearly" rule.
「間隔」パラメータは繰り返しルールが繰り返される頻度を表す正の整数が含まれています。デフォルト値は「第二に、」ルールの毎秒を意味し、「1」である、のための「微妙」ルール毎分、「時給」ルールの毎時、「毎日」ルールのため、毎日、毎週 "週刊」ルールのための毎月 『月刊』のルール、およびため、毎年 『毎年』のルール。
The "until" parameter defines an iCalendar COS DATE or DATE-TIME value which bounds the recurrence rule in an inclusive manner. If the value specified by "until" is synchronized with the specified recurrence, this date or date-time becomes the last instance of the recurrence. If specified as a date-time value, then it MUST be specified in UTC time format. If not present, and the "count" parameter is not also present, the recurrence is considered to repeat forever.
パラメータは、包括的な方法で繰り返しルールの境界のiCalendar COS日付または日時値を定義する「まで」。で指定された値が「まで」指定の再発と同期している場合は、この日付または日付時刻は、再発の最後のインスタンスになります。日付時刻値として指定した場合、それはUTC時刻形式で指定する必要があります。現在、そして「カウント」パラメータではありませんが、また、存在しない場合、再発は永遠に繰り返すように考えられています。
The "count" parameter defines the number of occurrences at which to range-bound the recurrence. The "dtstart" parameter counts as the first occurrence. The "until" and "count" parameters MUST NOT occur in the same "time" output.
「カウント」パラメータは再発を結合する範囲れる出現数を定義します。 「DTSTART」パラメータが最初に出現したとしてカウントされます。そして「カウント」パラメータが同じ「時間」出力に発生してはならない「まで」。
The "bysecond" parameter specifies a comma-separated list of seconds within a minute. Valid values are 0 to 59. The "byminute" parameter specifies a comma-separated list of minutes within an hour. Valid values are 0 to 59. The "byhour" parameter specifies a comma-separated list of hours of the day. Valid values are 0 to 23.
「BYSECOND」パラメータは分以内秒のカンマ区切りリストを指定します。有効な値は0〜59の「BYMINUTE」パラメータが時間以内分のカンマ区切りリストを指定します。有効な値は0〜59の「BYHOUR」パラメータは、一日の時間のコンマ区切りのリストを指定します。有効な値は0〜23です。
The "byday" parameter specifies a comma-separated list of days of the week. "MO" indicates Monday, "TU" indicates Tuesday, "WE" indicates Wednesday, "TH" indicates Thursday, "FR" indicates Friday, "SA" indicates Saturday, and "SU" indicates Sunday. These values are not case-sensitive.
「BYDAY」パラメータは、曜日のカンマ区切りリストを指定します。 「MO」は月曜日、「TU」は火曜日を示す示し、「WE」は、「FR」は金曜日を示し、水曜日、「TH」は木曜日を示す示し、「SA」土曜日示し、「SU」日曜日を示しています。これらの値は、大文字と小文字は区別されません。
Each "byday" value can also be preceded by a positive (+n) or negative (-n) integer. If present, this indicates the nth occurrence of the specific day within the "monthly" or "yearly" recurrence. For example, within a "monthly" rule, +1MO (or simply 1MO) represents the first Monday within the month, whereas -1MO represents the last Monday of the month. If an integer modifier is not present, it means all days of this type within the specified frequency. For example, within a "monthly" rule, MO represents all Mondays within the month.
各「BYDAY」値は、正（+ N）または負（-n）整数が先行することができます。存在する場合、これは「毎月」または「毎年」再発内の特定の日のn番目の発生を示します。たとえば、「月刊」ルール内、+ 1Mo鋼（または単に1Mo鋼）-1MOは、月の最後の月曜日を表し、一方、月以内に最初の月曜日を表します。整数修飾子が存在しない場合は、指定された周波数内でこのタイプのすべての日を意味します。たとえば、「月刊」ルールの中、MOは、月内のすべての月曜日を表します。
The "bymonthday" parameter specifies a comma-separated list of days of the month. Valid values are 1 to 31 or -31 to -1. For example, -10 represents the tenth to the last day of the month.
「BYMONTHDAY」パラメータは、月の日数をカンマで区切ったリストを指定します。有効値は1 -1〜31、または-31です。例えば、-10月の最終日に第十を表します。
The "byyearday" parameter specifies a comma-separated list of days of the year. Valid values are 1 to 366 or -366 to -1. For example, -1 represents the last day of the year (December 31st) and -306 represents the 306th to the last day of the year (March 1st).
「byyearday」パラメータは、今年の日のカンマ区切りリストを指定します。有効な値は-1に366から1又は-366です。例えば、-1年の最後の日（12月31日）を表し、-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 -1〜53、または-53です。これは、ISO 8601 [20]で定義されるように週番号付けによる週に相当します。週（「のWkst」を参照）週間のスタートとなるように定義週の日に開始し、7日間の期間として定義されます。暦年の週番号1は、その暦年中に少なくとも4日を含む最初の週です。このパラメータは、「毎年」のルールに対してのみ有効です。たとえば、3年の第3週を表します。
Note: Assuming a Monday week start, week 53 can only occur when January 1 is a Thursday or, for leap years, if January 1 is a Wednesday.
注意：1月1日が水曜日の場合は月曜日の週の開始を想定すると、週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よりも大きい間隔を持っており、「BYDAY」パラメータが指定されている場合、このことは重要です。これは、「BYWEEKNO」パラメータが指定されている「毎年」の再発にも重要です。デフォルト値は、ISO 8601 [20]以下、 "MO" です。
The "bysetpos" parameter specifies a comma-separated list of values which corresponds to the nth occurrence within the set of events specified by the rule. Valid values are 1 to 366 or -366 to -1. It MUST only be used in conjunction with another byxxx parameter. For example, "the last work day of the month" could be represented as:
「BYSETPOS」パラメータは、ルールによって指定されたイベントのセット内のn番目の発生に対応する値のカンマ区切りリストを指定します。有効な値は-1に366から1又は-366です。それだけで、別のbyxxxパラメータと組み合わせて使用する必要があります。たとえば、「月の最後の作業日は」として表すことができます。
<time -timerange- freq="monthly" byday="MO,TU,WE,TH,FR" bysetpos="-1">
<時間-timerange- FREQ = "毎月" BYDAY = "MO、TU、WE、TH、FR" BYSETPOS = " - 1">
Each "bysetpos" value can include a positive (+n) or negative (-n) integer. If present, this indicates the nth occurrence of the specific occurrence within the set of events specified by the rule.
各「BYSETPOS」値は正（+ N）または負（-n）整数を含むことができます。存在する場合、これはルールで指定されたイベントのセット内の特定の発生のn番目の発生を示します。
If byxxx parameter values are found which are beyond the available scope (i.e., bymonthday="30" in February), they are simply ignored.
byxxxパラメータ値が使用可能スコープ（月に、すなわち、BYMONTHDAY =「30」）を超えていた発見された場合、それらは単に無視されます。
Byxxx parameters modify the recurrence in some manner. Byxxx rule parts for a period of time which is the same or greater than the frequency generally reduce or limit the number of occurrences of the recurrence generated. For example, freq="daily" bymonth="1" reduces the number of recurrence instances from all days (if the "bymonth" parameter is not present) to all days in January. Byxxx parameters for a period of time less than the frequency generally increase or expand the number of occurrences of the recurrence. For example, freq="yearly" bymonth="1,2" increases the number of days within the yearly recurrence set from 1 (if "bymonth" parameter is not present) to 2.
Byxxxパラメータは、いくつかの方法で、再発を変更します。一般的に生成された再発の発生回数を低減または制限同一または周波数より大きい期間、Byxxxルール部品。例えば、FREQは=「毎日」BYMONTH =「1」月にすべての日に（「BYMONTH」パラメータが存在しない場合）すべての日から再発インスタンスの数を減少させます。周波数未満の時間の間Byxxxパラメータは、一般的再発の発生数を増加または拡張。 2（「BYMONTH」パラメータが存在しない場合）は、例えば、FREQ =「毎年」BYMONTH =「1,2」1からセット毎年再発日以内の数を増加させます。
If multiple Byxxx parameters are specified, then after evaluating the specified "freq" and "interval" parameters, the Byxxx parameters are applied to the current set of evaluated occurrences in the following order: "bymonth", "byweekno", "byyearday", "bymonthday", "byday", "byhour", "byminute", "bysecond", and "bysetpos"; then "count" and "until" are evaluated.
複数Byxxxパラメータが指定されている場合、指定された「FREQ」及び「間隔」パラメータを評価した後、Byxxxパラメータは、次の順序で評価オカレンスの現在のセットに適用される：「BYMONTH」、「BYWEEKNO」、「byyearday」、 "BYMONTHDAY"、 "BYDAY"、 "BYHOUR"、 "BYMINUTE"、 "BYSECOND"、および "BYSETPOS"。その後、評価され、「まで」「カウント」と。
Here is an example of evaluating multiple Byxxx parameters.
ここでは、複数のByxxxのパラメータを評価する例です。
<time dtstart="19970105T083000" duration="10M" freq="yearly" interval="2" bymonth="1" byday="SU" byhour="8,9" byminute="30">
<時間DTSTART = "19970105T083000" 期間= "10M" FREQ = "毎年" 間隔= "2" BYMONTH = "1" BYDAY = "SU" BYHOUR = "8,9" BYMINUTE = "30">
First, the interval="2" would be applied to freq="yearly" to arrive at "every other year." Then, bymonth="1" would be applied to arrive at "every January, every other year." Then, byday="SU" would be applied to arrive at "every Sunday in January, every other year." Then, byhour="8,9" would be applied to arrive at "every Sunday in January at 8 AM and 9 AM, every other year." Then, byminute="30" would be applied to arrive at "every Sunday in January at 8:30 AM and 9:30 AM, every other year." Then the second is derived from "dtstart" to end up in "every Sunday in January from 8:30:00 AM to 8:40:00 AM, and from and 9:30:00 AM to 9:40:00 AM, every other year." Similarly, if the "byminute", "byhour", "byday", "bymonthday", or "bymonth" parameter were missing, the appropriate minute, hour, day, or month would have been retrieved from the "dtstart" parameter.
まず、間隔=「2」が到着する=「毎年」FREQするために適用される「隔年。」その後、BYMONTH =「1」が到着して適用される「毎年1月、隔年。」その後、BYDAY =「SU」は到着に適用される「1月中毎週日曜日、隔年。」その後、BYHOUR =「8,9」に到着するために適用されるだろう「8 AMと9 AM、隔年で1月には毎週日曜日。」その後、BYMINUTE =「30」に到達するように適用される「8:30 9:30 AM、隔年で1月中毎週日曜日。」続いて第二は、八時40分00秒AMに午前8時30分00秒AMから1月に毎週日曜日」で終わるために「DTSTART」から派生してからと九時40分00秒AMに9時30分00秒AMれ、 1年おきに。"同様に、欠落していた「BYMINUTE」、「BYHOUR」、「BYDAY」、「BYMONTHDAY」、または「BYMONTH」パラメータ場合、適切な分、時間、日、または月には「DTSTART」パラメータから取得されていたであろう。
The iCalendar COS RDATE, EXRULE, and EXDATE recurrence rules are not specifically mapped to components of the time-switch node. Equivalent functionality to the exception rules can be attained by using the ordering of switch rules to exclude times using earlier rules; equivalent functionality to the additional-date RDATE rules can be attained by using "sub" nodes (see Section 8) to link multiple outputs to the same subsequent node.
iCalendarのCOS RDATE、EXRULE、およびEXDATE再発ルールは、具体的に時間スイッチノードのコンポーネントにマップされていません。例外ルールと同等の機能は、以前のルールを使用して時間を除外するためにスイッチルールの順序付けを使用することによって達成することができます。付加日付RDATE規則と同等の機能が同じ後続のノードに複数の出力をリンクする「サブ」ノード（セクション8を参照）を使用することによって達成することができます。
The "not-present" output is never true for a time switch. However, it MAY be included to allow switch processing to be more regular.
「-存在していない」出力は、タイムスイッチのための真のことはありません。しかし、スイッチの処理がより規則的であることを可能にするために含まれるかもしれません。
(This sub-sub-section is non-normative.)
（このサブサブセクションは非規範的です。）
The specification of recurring events in this section is identical (except for syntax and formatting issues) to that of RFC 2445 [8], with only one additional restriction. That one restriction is that consecutive instances of recurrence intervals may not overlap.
このセクションのイベント繰り返しの仕様は、唯一の追加の制限を有する、[8] RFC 2445と（構文およびフォーマットの問題を除いて）同一です。そのつの制限は、繰り返し間隔の連続したインスタンスが重複しないことです。
It was a matter of some debate, during the design of CPL, whether the entire iCalendar COS recurrence specification should be included in CPL, or whether only a subset should be included. It was eventually decided that compatibility between the two protocols was of primary importance. This imposes some additional implementation issues on implementors of CPL servers.
これは、全体のiCalendar COS再発仕様はCPLに含まれるべきかどうか、CPLの設計の際に、いくつかの議論の問題だった、またはサブセットのみが含まれるべきかどうか。それは、最終的に2つのプロトコル間の互換性が最も重要であったことを決定しました。これは、CPLサーバの実装にいくつかの追加の実装上の問題を課します。
It does not appear to be possible to determine, in constant time, whether a given instant of time falls within one of the intervals defined by a full iCalendar COS recurrence. The primary concerns are as follows:
時間の所与の瞬間がフルのiCalendar COS再発によって定義された間隔の1つに入るかどうかを、一定の時間で、決定することが可能であるようには見えません。次のように主な関心事は、以下のとおりです。
o The "count" parameter cannot be checked in constant running time, since it requires that the server enumerate all recurrences from "dtstart" to the present time, in order to determine whether the current recurrence satisfies the parameter. However, a server can expand a "count" parameter once, off-line, to determine the date of the last recurrence. This date can then be treated as a virtual "until" parameter for the server's internal processing.
それは、サーバが現在の再発がパラメータを満たしているかどうかを決定するために、現在の時刻に「DTSTART」からすべての再発を列挙することを必要とするため、O「カウント」パラメータは、一定の走行時間で確認することができません。ただし、サーバーは、最後の再発の日付を決定するために、オフライン、一度「カウント」パラメータを拡張することができます。この日付は、サーバの内部処理のためのパラメータ「まで」の仮想として扱うことができます。
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つのパラメータ、「大きい」、「以下」、または「等しい」のいずれかをとります。高い順に、「緊急」、「緊急」、「ノーマル」、および「非緊急」：これらのパラメータの値は、次の優先事項の一つです。これらの値は、大文字と小文字を区別しないように一致しています。 「少ない」パラメータと出力は等々、コールの優先順位は、引数に与えられた優先度よりも小さい場合に取る、とされています。
If no priority is specified in a message, the priority is considered to be "normal". If an unknown priority is specified in the call, it is considered to be equivalent to "normal" for the purposes of "greater" and "less" comparisons, but it is compared literally for "equal" comparisons.
何の優先順位がメッセージに指定されていない場合は、優先度が「普通」であると考えられています。未知の優先順位を呼び出しで指定されている場合、「より大きい」及び「以下」比較の目的のための「正常」に相当すると考えられるが、それは「等しい」の比較のために文字通り比較されます。
Since every message has a priority, the "not-present" output is never true for a priority switch. However, it MAY be included, to allow switch processing to be more regular.
すべてのメッセージは、優先順位を持っているので、「-存在しない」出力が優先スイッチのための真のことはありません。しかし、スイッチの処理がより規則的であることを可能にするために、含まれるかもしれません。
The priority of a SIP message corresponds to the "Priority" header in the initial "INVITE" message.
SIPメッセージの優先順位は、最初の「INVITE」メッセージの「優先度」ヘッダに相当します。
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.
明示的な位置ノードは、三個のノードのパラメータを有します。必須「URL」パラメータの値は、ロケーションセットに追加するアドレスのURLです。唯一つのアドレスは、ロケーション・ノードごとに指定することができます。複数の位置は、これらのノードをカスケード接続することによって指定することができます。
The optional "priority" parameter specifies a priority for the location. Its value is a floating-point number between 0.0 and 1.0. If it is not specified, the server SHOULD assume a default priority of 1.0. The optional "clear" parameter specifies whether the location set should be cleared before adding the new location to it. Its value can be "yes" or "no", with "no" as the default.
オプションの「優先度」パラメータは、場所の優先順位を指定します。その値は0.0と1.0の間の浮動小数点数です。それが指定されていない場合、サーバーは、1.0のデフォルトの優先度を想定すべきです。オプションの「クリア」パラメータは、ロケーションセットがそれに新しい場所を追加する前にクリアする必要があるかどうかを指定します。その値は「yes」または「no」、デフォルトとして「なし」とすることができます。
Basic location nodes have only one possible result, since there is no way that they can fail. (If a basic location node specifies a location which isn't supported by the underlying signalling protocol, the script server SHOULD detect this and report it to the user at the time the script is submitted.) Therefore, their XML representations do not have explicit output tags; the <location> tag directly contains another node.
彼らは失敗することができます方法はありませんので、基本的な場所ノードは、唯一の可能な結果を持っています。 （基本的な位置ノードは、基礎となるシグナリングプロトコルによってサポートされていない場所を指定している場合、スクリプトサーバは、これを検出し、スクリプトが提出された時点でユーザーにそれを報告しなければならない。）ので、そのXML表現が明示的にありません出力タグ。 <場所>タグは、直接別のノードを含みます。
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
ノード：「検索」出力：検索が成功した場合、「成功」の次のノード「NOTFOUND」次ノードルックアップが見つかった場合は何のアドレスない「失敗」次のノードであれば、ルックアップに失敗しましたパラメータ：ソースの前にしようとする時、「タイムアウト」のルックアップの「ソース」新しい値を追加する前に、ロケーションセットをクリアするかどうかを「クリア」のルックアップをあきらめます
Output: "success" Parameters: none
出力：「成功」パラメータ：なし
Output: "notfound" Parameters: none
出力：「NOTFOUND」パラメータ：なし
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であるならば、それは（[また、RFC 2483に表示される、このタイプのIANA登録を参照してくださいCPLサーバーは、uriテキスト/リストメディアタイプを持つオブジェクトを取得するために照会することができる場所を示します10]）。 （例えばURIパラメータなど）は、追加情報が加えられないとクエリは、そのまま実行されます。サーバは、ロケーションセットに、このオブジェクトに含まれている場所を追加します。
CPL servers MAY refuse to allow URI-based sources for location queries for some or all URI schemes. In this case, they SHOULD reject the script at script upload time.
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.
（例えば）CGIスクリプトは、それらを解決するために使用することができるように、CPLサーバは、ロケーション要求にURIパラメータを追加したの議論がなされてきました。しかし、コンセンサスは、これは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.
「成功」、「NOTFOUND」、および「失敗」：検索は、3つの出力があります。 NOTFOUNDは、ルックアップ・プロセスが成功した場合にとられるが、任意の場所を見つけることができませんでした。検索は、指定されたタイムアウトを超過したことを含め、何らかの理由で失敗した場合に障害がとられています。与えられた出力が存在しない場合、スクリプトの実行が終了し、デフォルトの動作が行われます。
For SIP, the "registration" lookup source corresponds to the locations registered with the server using "REGISTER" messages.
SIPについては、「登録」参照元は「REGISTER」メッセージを使用してサーバに登録場所に対応しています。
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つのオプションのパラメータを有しています。パラメータ「場所」は、シグナリングプロトコル依存性の様式で、セットから除去される位置の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."
シグナリング演算ノードは、基礎となるシグナリングプロトコルでのシグナル伝達事象を引き起こします。三つのシグナル伝達の操作が定義されています：「プロキシ」、「リダイレクト」と「拒否します」。
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.
ノード：「プロキシ」出力：「忙しい」次ノードのコールしようとすると次のノードの障害「を「コール試行がリダイレクトされた場合、次のノード」リダイレクト「コールの試行がタイムアウトする前に応答しなかった場合は次のノード」コールの試行が「忙しい」」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つに対応する次のノードが取られます。コールがリダイレクトされた、と「失敗」の場合は続いている場合は「タイムアウト」パラメータの期限が切れる前にコールが応答されなかった場合、コールがビジー状態だった場合、「忙しい」出力が続いている、「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つの値を取ることができ、「再帰」、である、「はい」または「いいえ」。これは、サーバーが自動的に初期サーバから返されたリダイレクト応答でアドレスをテレフォニーするため、さらにコールの試みを配置しようとするかどうかを指定します。 「再帰」の値が「はい」であれば、スクリプトに「リダイレクト」の出力が取られないことに注意してください。この場合、この出力は存在してはなりません。このパラメータのデフォルト値は「yes」です。
The third optional parameter is "ordering". This can have three possible values: "parallel", "sequential", and "first-only". This parameter specifies in what order the locations of the location set should be tried. Parallel asks that they all be tried simultaneously; sequential asks that the one with the highest priority be tried first, the one with the next-highest priority second, and so forth, until one succeeds or the set is exhausted. First-only instructs the server to try only the highest-priority address in the set, and then follow one of the outputs. The priority of locations in a set is determined by server policy, though CPL servers SHOULD honor the "priority" parameter of the "location" tag. The default value of this parameter is "parallel".
第三オプションのパラメータは、「発注」です。 「平行」、「順次」、および「最初のみ」：これは3つの値を持つことができます。このパラメータは、ロケーションセットの位置が試されるべきどのような順序で指定します。パラレルは、それら全てが同時に試みられることを要求します。シーケンシャルは1つが成功するかセットが使い果たされるまで優先順位が最も高い一つは、等、最初に試み次に高い優先順位の第有するものとすることが求められます。まずのみのセットのみで、最も優先順位の高いアドレスを試し、その後、出力のいずれかを追跡するために、サーバーに指示します。 CPLサーバーは、「場所」タグの「優先度」パラメータを尊重すべきであるにもかかわらずセット内の位置の優先順位は、サーバーポリシーによって決定されます。このパラメータのデフォルト値は「平行」です。
Once a proxy operation completes, if control is passed on to other nodes, all locations which have been used are cleared from the location set. That is, the location set is emptied of proxyable locations if the "ordering" was "parallel" or "sequential"; the highest-priority item in the set is removed from the set if "ordering" was "first-only". (In all cases, non-proxyable locations such as "http" URIs remain.) In the case of a "redirection" output, the new addresses to which the call was redirected are then added to the location set.
プロキシ操作が完了すると、制御は、他のノードに渡された場合、使用されてきたすべてのロケーションは、ロケーションセットからクリアされます。 「順序」が「平行」または「順次」であった場合には、位置セットはproxyable位置の空です。 「順序」は「最初だけ」だった場合のセットで最も優先度の高い項目が集合から削除されます。 （全ての場合において、このような「HTTP」のURIなどの非proxyable位置が残る。）「リダイレクション」出力の場合には、コールがリダイレクトした新しいアドレスは、その後、位置セットに追加されます。
For SIP, the best response to a "proxy" node is determined by the algorithm of the SIP specification. The node's outputs correspond to the following events:
SIPについては、「プロキシ」ノードへの最良の応答は、SIP仕様のアルゴリズムによって決定されます。ノードの出力は、次のイベントに対応しています。
busy: A 486 or 600 response was the best response received for the call request.
忙しい：486または600応答は、呼要求のために受け取った最高の応答でした。
redirection: A 3xx response was the best response received for the call request.
リダイレクト：3xx応答は、呼要求のために受け取った最高の応答でした。
failure: Any other 4xx, 5xx, or 6xx response was the best response received for the call request.
失敗：その他の4xx、5xx、または6xx応答は、呼要求のために受け取った最高の応答でした。
no-answer: No final response was received for the call request before the timeout expired.
無応答：タイムアウトの期限が切れる前に何最終応答は、呼要求のために受信されませんでした。
SIP servers SHOULD honor the "q" parameter of SIP registrations when determining location priority.
場所の優先順位を決定する際にSIPサーバは、SIP登録の「Q」のパラメータを尊重すべきです。
Redirect causes the server to direct the calling party to attempt to place its call to the currently specified set of locations. The syntax of this node is specified in Figure 13.
リダイレクトは、場所の現在指定セットにその電話をかけしようとする発信者に指示するために、サーバーが発生します。このノードの構文は、図13で指定されています。
The specific behavior the redirect node invokes is dependent on the underlying signalling protocol involved, though its semantics are generally applicable.
そのセマンティクスが一般的に適用されてもリダイレクトノードが呼び出す特定の動作は、関与する基礎となるシグナリングプロトコルに依存しています。
Node: "redirect"
Outputs: None (No node may follow)
Next node: None
Parameters: "permanent" Whether the redirection should be
considered permanent
Figure 13: Syntax of the "redirect" node
図13：「リダイレクトする」ノードのシンタックス
Redirect immediately terminates execution of the CPL script, so this node has no outputs and no next node. It has one parameter, "permanent", which specifies whether the result returned should indicate that this is a permanent redirection. The value of this parameter is either "yes" or "no" and its default value is "no."
リダイレクトすぐには、CPLスクリプトの実行を終了するので、このノードは出力なし次のノードを持っていません。これは、結果が、これは永久的なリダイレクトであることを示す必要があるかどうかを指定する返され、「永久」、一つのパラメータを持っています。このパラメータの値は、「はい」または「いいえ」のどちらかであり、そのデフォルト値は「いいえ。」
The SIP server SHOULD send a 3xx class response to a call request upon executing a "redirect" tag. If "permanent" was "yes", the server SHOULD send the response "301" (Moved permanently), otherwise it SHOULD send "302" (Moved temporarily).
SIPサーバは、「リダイレクト」タグを実行時に呼び出し要求に対する3xxクラスの応答を送るべきです。 「永久」は「YES」であった場合は、サーバが「301」の応答を送信すべきである（恒久的に移動）、それ以外の場合は「302」（一時的に移動）を送信すべきです。
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.
Aノードを拒否し、直ちに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つの引数を持っています。 「状態」引数は必要とされ、値「ビジー」、「NOTFOUND」、「拒否」、「エラー」、またはシグナリングプロトコルに定義された状態のいずれかをとることができます。
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にSIP状況に対応する引数、5xxの、または6xxの範囲であることを許可する必要があります。
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」mailtoのURL、メールが送らすべき
Figure 15: Syntax of the "mail" node
図15：「メール」ノードの構文
The "mail" node takes one argument: a "mailto" URL giving the address, and any additional desired parameters, of the mail to be sent. The server sends the message containing the content to the given url; it SHOULD also include other status information about the original call request and the CPL script at the time of the notification.
アドレスを与える「MAILTO」URL、および送信されるメールの任意のさらなる所望のパラメータ、：「メール」ノードは、1つの引数を取ります。サーバーは、指定した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" />.
<：/「？=ルック％20failed jones@example.com対象のmailto」メールURL =>フル「のmailto」URLだけではなく、電子メールアドレスを使用すると、追加の電子メールヘッダのような、指定することができます。
A mail node has only one possible result, since failure of e-mail delivery cannot reliably be known in real time. Therefore, its XML representation does not have output tags: the <mail> tag directly contains another node tag.
電子メール配信の失敗が確実にリアルタイムで知ることができないため、メールノードは、唯一の可能な結果を持っています。したがって、そのXML表現を出力タグを持っていません：<メール>タグは、直接他のノードのタグが含まれています。
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にパラメータの区切りとして使用されているアンパサンド文字は、「＆」、として引用されている必要があります「＆＃038;」パラメータ値内部（XML仕様のセクションC.12 [2]を参照）。
This section presents suggested guidelines for the mail sent as a result of the "mail" node, for requests triggered by SIP. The message mailed (triggered by any protocol) SHOULD contain all this information, but servers MAY elect to use a different format.
このセクションプレゼントは、SIPによってトリガ要求に対して、「メール」ノードの結果として送信されるメールのためのガイドラインを提案しました。 （任意のプロトコルによってトリガ）郵送メッセージは、すべての情報を含むべきであるが、サーバは、異なるフォーマットを使用することを選択することができます。
1. If the "mailto" URI did not specify a subject header, the subject of the e-mail is "[CPL]", followed by the subject header of the SIP request. If the URI specified a subject header, it is used instead.
1「のmailto」URIは、対象のヘッダを指定しなかった場合、電子メールの件名は、SIP要求の対象ヘッダに続く「[CPL]」です。 URIは、対象ヘッダを指定した場合、それが代わりに使用されます。
2. The "From" field of the e-mail is set to a CPL server configured address, overriding any "From" field in the "mailto" URI.
2.電子メールのフィールドは、「のmailto」URI内の任意の「From」フィールドを上書きし、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：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
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サーバーは、今までに失敗する「ログ」イベントを許してはなりません。そのため、ログのノードが唯一の可能な結果を持つことができ、そしてそのXML表現は、明示的な出力タグを持っていません。 CPL <ログ>タグは、直接他のノードのタグが含まれています。
XML syntax defines a tree. To allow more general call flow diagrams, and to allow script re-use and modularity, we define subactions.
XML構文では、ツリーを定義します。より一般的なコール・フロー図を許可するには、スクリプトの再利用およびモジュール性を可能にするために、我々はサブアクションを定義します。
Two tags are defined for subactions: subaction definitions and subaction references. Their syntax is given in Figure 17.
サブアクションの定義とサブアクション参照：二つのタグがサブアクションのために定義されています。その構文は、図17に示されています。
Tag: "subaction"
Subtags: Any node
Parameters: "id" Name of this subaction
Pseudo-node: "sub" Outputs: None in XML tree Parameters: "ref" Name of subaction to execute
擬似ノード：「サブ」出力：XMLツリーパラメータでなし：「REF」サブアクションの名前を実行します
Figure 17: Syntax of subactions and "sub" pseudo-nodes
図17：サブアクションと「サブ」疑似ノードのシンタックス
Subactions are defined through "subaction" tags. These tags are placed in the CPL script after any ancillary information (see Section 9), but before any top-level tags. They take one argument: "id", a token indicating a script-chosen name for the subaction. The "id" value for every "subaction" tag in a script MUST be unique within that script.
サブアクションは、「サブアクション」タグによって定義されています。これらのタグは任意の補助的な情報（セクション9を参照）した後、しかし、任意のトップレベルのタグの前にCPLスクリプトに配置されています。 「ID」、サブアクションのスクリプトが選択した名前を示すトークン：彼らは一つの引数を取ります。スクリプト内のすべての「サブアクション」タグの「ID」の値は、そのスクリプト内で一意でなければなりません。
Subactions are called from "sub" tags. The "sub" tag is a "pseudo-node", and can be used anyplace in a CPL action that a true node could be used. It takes one parameter, "ref", the name of the subaction to be called. The "sub" tag contains no outputs of its own, instead control passes to the subaction.
サブアクションは、「サブ」タグから呼ばれています。 「サブ」タグは、「疑似ノード」であり、真のノードを使用することができるCPLアクションでどこでも使用することができます。これは、サブアクションの名前が呼ばれるように、一つのパラメータ、「参照」を取ります。 「サブ」タグは、それ自身の出力を含まず、代わりにサブアクションへのパスを制御します。
References to subactions MUST refer to subactions defined before the current action. A "sub" tag MUST NOT refer to the action it appears in, or to any action defined later in the CPL script. Top-level actions cannot be called from "sub" tags, or through any other means. Script servers MUST verify at the time the script is submitted that no "sub" node refers to any subaction that is not its proper predecessor.
サブアクションへの参照は、現在のアクションの前に定義されたサブアクションを参照する必要があります。 「サブ」タグは、それが中に表示される、またはCPLスクリプトの後半で定義された任意のアクションにアクションを参照してはなりません。トップレベルのアクションは「サブ」タグから、またはその他の手段を通じて呼び出すことはできません。スクリプトサーバーは、スクリプトがない「サブ」ノードはその適切な前任者ではありません任意のサブアクションを意味しないことが提出された時点で確かめなければなりません。
Allowing only back-references of subs forbids any sort of recursion. Recursion would introduce the possibility of non-terminating or non-decidable CPL scripts, a possibility our requirements specifically excluded.
潜水艦の唯一の後方参照を許可すると、再帰の任意の並べ替えを禁止します。再帰は非終端または非決定可能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スクリプト内のタイムゾーンの定義を含めることが有用であり得ます。もしそうであれば、拡張子はここでそれらを含むように定義することができます。
Tag: "ancillary"
Parameters: None
Subtags: None
Figure 18: Syntax of the "ancillary" tag
図18：「補助的」タグの構文
When a CPL node reaches an unspecified output, either because the output tag is not present, or because the tag is present but does not contain a node, the CPL server's behavior is dependent on the current state of script execution. This section gives the operations that should be taken in each case.
CPLノードが未指定の出力に到達すると、いずれかのため、出力タグが存在しない、またはタグが存在しているが、ノードが含まれていないため、CPLサーバーの動作は、スクリプトの実行の現在の状態に依存しています。このセクションでは、それぞれの場合にとるべき動作を与えます。
no location modifications or signalling operations performed, location set empty: Look up the user's location through whatever mechanism the server would use if no CPL script were in effect. Proxy, redirect, or send a rejection message, using whatever policy the server would use in the absence of a CPL script.
何のCPLスクリプトが有効でなかった場合は、サーバーが使用するどのようなメカニズムを介してユーザの位置を見上げて：なし場所の変更またはシグナリング操作が場所が空に設定され、実行されません。プロキシは、サーバがCPLスクリプトが存在しない場合に使用するものは何でもポリシー使用して、リダイレクト、または拒否メッセージを送信します。
no location modifications or signalling operations performed, location set non-empty: (This can only happen for outgoing calls.) Proxy the call to the addresses in the location set.
位置セットのアドレスに（これが唯一の発信コールのために起こることができる。）プロキシコール：なし位置の修正またはシグナリングオペレーションは、位置非空集合を行いません。
location modifications performed, no signalling operations: Proxy or redirect the call, whichever is the server's standard policy, to the addresses in the current location set. If the location set is empty, return a "notfound" rejection.
現在位置のセットのアドレスに、サーバの標準ポリシー方コールを、プロキシまたはリダイレクト：位置の変更は、いかなるシグナリング動作を行いません。場所のセットが空の場合、「NOTFOUND」拒絶反応を返します。
noanswer output of proxy, no timeout given: (This is a special case.) If the "noanswer" output of a proxy node is unspecified, and no timeout parameter was given to the proxy node, the call should be allowed to ring for the maximum length of time allowed by the server (or the request, if the request specified a timeout).
プロキシの出力noanswer、タイムアウトが与えられていない（これは特別な場合である。）プロキシノードの「noanswer」出力が指定されていない、およびタイムアウトパラメータがプロキシノードに与えられなかった場合は、呼がためリングさせなければなりません（リクエストがタイムアウトを指定した場合、または要求）サーバによって許可された時間の最大長。
proxy operation previously taken: Return whatever the "best" response is of all accumulated responses to the call to this point, according to the rules of the underlying signalling protocol.
プロキシの動作は、以前に撮影した：リターンを「最良の」応答は、基礎となるシグナリングプロトコルのルールに従って、この時点までの呼び出しに対するすべての累積応答のあるものは何でも。
Servers MAY support additional CPL features beyond those listed in this document. Some of the extensions which have been suggested are a means of querying how a call has been authenticated, richer control over H.323 addressing, end-system or administrator-specific features, regular-expression matching for strings and addresses, and mid-call or end-of-call controls.
サーバーは、この文書に記載された値を超える追加のCPL機能をサポートするかもしれません。提案されている拡張子の一部は、コールが認証されているか照会する手段、H.323を超える豊かな制御のアドレッシング、エンド・システムまたは管理者固有の機能、文字列とアドレス、および通話中のために一致する正規表現ですまたは終了のコールを制御します。
CPL extensions are indicated by XML namespaces [11]. Every extension MUST have an appropriate XML namespace assigned to it. The XML namespace of the extension MUST be different from the XML namespace 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名前空間を持たなければなりません。この文書で定義されたCPLスキーマの構文やセマンティクスを変更してはなりません拡張のXML名前空間は、セクション14の拡張で定義されたXML名前空間と異なっている必要があります。その名前空間内に配置するように拡張の一部であるすべてのXMLタグと属性が適切に修飾する必要があります。
Tags or attributes in a CPL script which are in the global namespace (i.e., not associated with any namespace) are equivalent to tags and attributes in the CPL namespace "urn:ietf:params:xml:ns:cpl".
タグまたはグローバル名前空間にあるCPLスクリプトの属性（すなわち、任意の名前空間に関連付けられていない）タグと同等であり、CPLの名前空間の属性「URN：IETF：のparams：XML：NS：CPL」。
A CPL script SHOULD NOT specify any namespaces it does not use. For compatibility with non-namespace-aware parsers, a CPL script MAY omit the base CPL namespace for a script which does not use any extensions.
CPLスクリプトは、それが使用されていない任意の名前空間を指定しないでください。非名前空間を認識するパーサーとの互換性のため、CPLスクリプトは、任意の拡張子を使用していないスクリプトの基本CPLの名前空間を省略することができます。
A CPL server MUST reject any script containing a reference to a namespace it does not understand. It MUST reject any script containing an extension tag or attribute that is not qualified to be in an appropriate namespace.
CPLサーバーは、それが理解していない名前空間への参照を含む任意のスクリプトを拒絶しなければなりません。これは、適切な名前空間にあると修飾されていない拡張タグや属性を含む任意のスクリプトを拒絶しなければなりません。
A syntax such as
このような構文
<extension-switch> <extension has="http://www.example.com/foo"> [extended things] </extension> <otherwise> [non-extended things] </otherwise> </extension-switch>
<拡張スイッチ> <拡張有し=「http://www.example.com/foo」> [拡張もの</拡張> <さもなければ> [非拡張もの</さもなければ> </拡張スイッチ>
was suggested as an alternate way of handling extensions. This would allow scripts to be uploaded to a server without requiring a script author to somehow determine which extensions a server supports. However, experience developing other languages, notably Sieve [22], was that this added excessive complexity to languages. The "extension-switch" tag could, of course, itself be defined in a CPL extension.
拡張子を処理する別の方法として提案されました。これは、何らかの形で、サーバーがサポートする拡張モジュールをするかを決定するためのスクリプトの作者を必要とせずに、スクリプトをサーバにアップロードすることが可能となります。しかし、他の言語の開発経験、特にふるい[22]、これは言語に過度の複雑さを追加したことでした。 「拡張スイッチ」タグは、もちろん、それ自体は、CPL拡張で定義することができます。
In the XML schema of CPL, we introduce three abstract elements, namely 'toplevelaction', 'switch', and 'action', which accordingly have the abstract type 'TopLevelActionType', 'SwitchType', and 'ActionType'. Any top-level action in a CPL extension MUST be defined as the substitutionGroup of the abstract 'toplevelaction' element, and have the type extended from the 'TopLevelActionType'. Any switch in a CPL extension MUST be defined as the substitutionGroup of the abstract 'switch' element, and have the type extended from the 'SwitchType'. Any action in a CPL extension MUST be defined as the substitutionGroup of the abstract 'action' element, and have the type extended from the 'ActionType'.
CPLのXMLスキーマでは、我々はそれに応じて、抽象型「TopLevelActionType」、「SWITCHTYPE」、および「ACTIONTYPE」を持っている3つの抽象要素、すなわち「toplevelaction」、「スイッチ」、および「アクション」を紹介します。 CPL拡張の任意のトップレベルのアクションは、抽象「toplevelaction」要素ののsubstitutionGroupとして定義されなければならない、とタイプが「TopLevelActionType」から延びています。 CPL拡張のいずれかのスイッチは、抽象「スイッチ」要素のsubstitutionGroupとして定義されなければならない、とタイプが「SWITCHTYPE」から延びています。 CPL拡張の任意のアクションは、抽象「作用」要素ののsubstitutionGroupとして定義されなければならない、とタイプが「ACTIONTYPE」から延びています。
The script in Figure 19 is a simple script that redirects all calls to a single fixed location.
図19のスクリプトは、単一の固定された場所にすべてのコールをリダイレクトする簡単なスクリプトです。
<?xml version="1.0" encoding="UTF-8"?> <cpl xmlns="urn:ietf:params:xml:ns:cpl" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="urn:ietf:params:xml:ns:cpl cpl.xsd "> <incoming> <location url="sip:smith@phone.example.com"> <redirect/> </location> </incoming> </cpl>
<？xml version = "1.0" エンコード= "UTF-8"？> <CPLののxmlns = "壷：IETF：のparams：XML：NS：CPL" のxmlns：XSI = "http://www.w3.org/2001 / XMLスキーマ・インスタンス」のxsi：のschemaLocation = "URN：IETF：paramsは：XML：NS：CPL cpl.xsd "> <着信> <場所のURL =" SIP：smith@phone.example.com"> <リダイレクト/> < /場所> </着信> </ CPL>
Figure 19: Example Script: Call Redirect Unconditional
図19：スクリプト例：コールリダイレクト無条件
The script in Figure 20 illustrates some more complex behavior. We see an initial proxy attempt to one address, with further operations if that fails. We also see how several outputs take the same action subtree, through the use of subactions.
図20のスクリプトは、いくつかのより複雑な挙動を示しています。それが失敗した場合、我々はさらに操作して、一つのアドレスに初期のプロキシの試みを参照してください。我々はまた、いくつかの出力がサブアクションを使用して、同じアクションサブツリーを取る方法を参照してください。
<?xml version="1.0" encoding="UTF-8"?> <cpl xmlns="urn:ietf:params:xml:ns:cpl" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="urn:ietf:params:xml:ns:cpl cpl.xsd "> <subaction id="voicemail"> <location url="sip:jones@voicemail.example.com"> <proxy/> </location> </subaction> <incoming> <location url="sip:jones@jonespc.example.com"> <proxy timeout="8"> <busy> <sub ref="voicemail"/> </busy> <noanswer> <sub ref="voicemail"/> </noanswer> </proxy> </location> </incoming> </cpl>
<？xml version = "1.0" エンコード= "UTF-8"？> <CPLののxmlns = "壷：IETF：のparams：XML：NS：CPL" のxmlns：XSI = "http://www.w3.org/2001 / XMLスキーマ・インスタンス」のxsi：のschemaLocation = "URN：IETF：paramsは：XML：NS：> jones@voicemail.example.com "：CPLは "> <サブアクションID =" ボイスメール"> <場所のURL =" SIPをcpl.xsd <プロキシ/> </場所> </サブアクション> <着信> <場所のURL = "SIP：jones@jonespc.example.com"> <ビジー> <サブREF = "ボイスメール" <= "8" プロキシタイムアウト> / > </ビジー> <noanswer> <サブREF = "ボイスメール" /> </ noanswer> </プロキシ> </場所> </着信> </ 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>
<？xml version = "1.0" エンコード= "UTF-8"？> <CPLののxmlns = "壷：IETF：のparams：XML：NS：CPL" のxmlns：XSI = "http://www.w3.org/2001 / XMLスキーマ・インスタンス」のxsi：のschemaLocation = "URN：IETF：paramsは：XML：NS：CPL cpl.xsd "> <着信> <場所のURL =" SIP：jones@jonespc.example.com"> <プロキシ> <リダイレクト> <リダイレクト/> </リダイレクト> <デフォルト> <場所のurl = "一口：jones@voicemail.example.com"> <プロキシ/> </場所> </デフォルト> </プロキシ> </場所> </入> </ CPL>
Figure 21: Example Script: Call Forward: Redirect and Default
図21：スクリプト例：電話転送：リダイレクトとデフォルト
The script in Figure 22 illustrates address switches and call rejection, in the form of a call screening script. Note also that because the address-switch lacks an "otherwise" clause, if the initial pattern does not match, the script does not define any operations. The server therefore proceeds with its default behavior, which would presumably be to contact the user.
図22のスクリプトは、アドレススイッチを示し、呼スクリーニングスクリプトの形で、拒絶反応を呼び出します。注また、アドレススイッチが「それ以外」句がないため、初期パターンが一致しない場合、スクリプトは任意の操作を定義しないこと。サーバは、それゆえ、おそらくユーザーに連絡することであろうそのデフォルトの動作、に進みます。
<?xml version="1.0" encoding="UTF-8"?> <cpl xmlns="urn:ietf:params:xml:ns:cpl" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="urn:ietf:params:xml:ns:cpl cpl.xsd "> <incoming> <address-switch field="origin" subfield="user"> <address is="anonymous"> <reject status="reject" reason="I reject anonymous calls"/> </address> </address-switch> </incoming> </cpl>
<？xml version = "1.0" エンコード= "UTF-8"？> <CPLののxmlns = "壷：IETF：のparams：XML：NS：CPL" のxmlns：XSI = "http://www.w3.org/2001 / XMLスキーマ・インスタンス "のxsi：のschemaLocation = "URN：IETF：paramsは：XML：NS：CPL cpl.xsd "> <着信> <アドレス・スイッチ・フィールドは=" 原点" サブフィールドは= "ユーザ"> <アドレス=は" 匿名> "/> </アドレス> </アドレス・スイッチ> </入> </ CPL「理由=" 私は匿名のコールを拒否拒否 "> <ステータス=拒否"
Figure 22: Example Script: Call Screening
図22：スクリプト例：コールスクリーニング
The script in Figure 23 illustrates service selection based on a call's priority value and language settings. If the call request had a priority of "urgent" or higher, the default script behavior is performed. Otherwise, the language field is checked for the language "es" (Spanish). If it is present, the call is proxied to a Spanish-speaking operator; other calls are proxied to an English-speaking operator.
図23のスクリプトは、コールのプライオリティ値と言語の設定に基づいてサービスの選択を示しています。コール要求は、「緊急」以上の優先順位を持っていた場合、デフォルトのスクリプトの動作が行われます。それ以外の場合は、言語フィールドは、言語「ES」（スペイン語）のためにチェックされています。それが存在する場合、コールはスペイン語を話すオペレーターにプロキシされます。他の呼び出しは英語を話すオペレータにプロキシされています。
<?xml version="1.0" encoding="UTF-8"?> <cpl xmlns="urn:ietf:params:xml:ns:cpl" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="urn:ietf:params:xml:ns:cpl cpl.xsd "> <incoming> <priority-switch> <priority greater="urgent"/> <otherwise> <language-switch> <language matches="es"> <location url="sip:spanish@operator.example.com"> <proxy/> </location> </language> <otherwise> <location url="sip:english@operator.example.com"> <proxy/> </location> </otherwise> </language-switch> </otherwise> </priority-switch> </incoming> </cpl>
<？xml version = "1.0" エンコード= "UTF-8"？> <CPLののxmlns = "壷：IETF：のparams：XML：NS：CPL" のxmlns：XSI = "http://www.w3.org/2001 / XMLスキーマ・インスタンス」のxsi：のschemaLocation = "URN：IETF：paramsは：XML：NS：CPL cpl.xsd "> <着信> <優先スイッチ> <優先大きく=" 緊急" /> <そうでない> <言語スイッチ> <言語マッチ= "ES"> <場所のurl = "一口：spanish@operator.example.com"> <プロキシ/> </場所> </言語> <そう> <場所のURL = "一口：英語@演算子.example.comの "> <プロキシ/> </場所> </さもなければ> </言語スイッチ> </さもなければ> </優先スイッチ> </着信> </ CPL>
Figure 23: Example Script: Priority and Language Routing
図23：スクリプト例：優先順位と言語のルーティング
The script in Figure 24 illustrates a script filtering outgoing calls, in the form of a script which prevent 1-900 (premium) calls from being placed. This script also illustrates subdomain matching.
図24のスクリプトが配置されているから呼び出し1-900（プレミアム）を防止するスクリプトの形式で、発信コールをフィルタリングするスクリプトを示します。このスクリプトは、サブドメインマッチングを示しています。
<?xml version="1.0" encoding="UTF-8"?> <cpl xmlns="urn:ietf:params:xml:ns:cpl" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="urn:ietf:params:xml:ns:cpl cpl.xsd "> <outgoing> <address-switch field="original-destination" subfield="tel"> <address subdomain-of="1900"> <reject status="reject" reason="Not allowed to make 1-900 calls."/> </address> </address-switch> </outgoing> </cpl>
<？xml version = "1.0" エンコード= "UTF-8"？> <CPLののxmlns = "壷：IETF：のparams：XML：NS：CPL" のxmlns：XSI = "http://www.w3.org/2001 / XMLスキーマ・インスタンス」のxsi：のschemaLocation = "URN：IETF：paramsは：XML：NS：CPLのcpl.xsd "> <発信> <アドレス・スイッチ・フィールド=" オリジナル先" サブフィールド= "TEL"> <アドレスsubdomain-の= "1900"> <ステータス= "拒否" 拒絶理由= "未1-900電話をかけることができました。" /> </アドレス> </アドレス・スイッチ> </送信> </ CPL>
Figure 24: Example Script: Outgoing Call Screening
図24：スクリプト例：発信コールスクリーニング
Figure 25 illustrates time-based conditions and timezones.
図25は、時間ベースの条件とタイムゾーンを示しています。
<?xml version="1.0" encoding="UTF-8"?> <cpl xmlns="urn:ietf:params:xml:ns:cpl" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="urn:ietf:params:xml:ns:cpl cpl.xsd "> <incoming> <time-switch tzid="America/New_York" tzurl="http://zones.example.com/tz/America/New_York"> <time dtstart="20000703T090000" duration="PT8H" freq="weekly" byday="MO,TU,WE,TH,FR"> <lookup source="registration"> <success> <proxy/> </success> </lookup> </time> <otherwise> <location url="sip:jones@voicemail.example.com"> <proxy/> </location> </otherwise> </time-switch> </incoming> </cpl>
<？xml version = "1.0" エンコード= "UTF-8"？> <CPLののxmlns = "壷：IETF：のparams：XML：NS：CPL" のxmlns：XSI = "http://www.w3.org/2001 / XMLスキーマ・インスタンス "のxsi：schemaLocationの= "壷：IETF：のparams：XML：NS：CPLのcpl.xsd "> <入> <タイムスイッチTZID =" アメリカ/ニューヨーク" tzurl =" のhttp：//zones.example .COM / TZ /アメリカ/ニューヨーク "> <時間DTSTART =" 20000703T090000" 期間= "PT8H" FREQ = "毎週" BYDAY = "MO、TU、WE、TH、FR"> <参照元= "登録"> <成功> <プロキシ/> </成功> </ルックアップ> </時間> <そう> <場所のURL = "一口：jones@voicemail.example.com"> <プロキシ/> </場所> </そうでありません> < /タイムスイッチ> </着信> </ CPL>
Figure 25: Example Script: Time-of-day Routing
図25：スクリプト例：time-of-dayルーティング
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>
<？xml version = "1.0" エンコード= "UTF-8"？> <CPLののxmlns = "壷：IETF：のparams：XML：NS：CPL" のxmlns：XSI = "http://www.w3.org/2001 / XMLスキーマ・インスタンス "のxsi：のschemaLocation = "URN：IETF：paramsは：XML：NS：CPL cpl.xsd "> <着信> <文字列スイッチフィールド=" ユーザエージェント"> <文字列=は" 不適切なソフトウェアSIPユーザエージェント/ 0.9beta2 "> <参照元=" 登録 "> <成功> <削除-場所場所=" SIP：me@mobile.provider.net "> <プロキシ/> </削除-場所> </成功> < /検索> </文字列> </文字列スイッチ> </入> </ CPL>
Figure 26: Example Script: Location Filtering
図26：スクリプト例：場所のフィルタリング
Figure 27 illustrates non-signalling operations; in particular, alerting a user by electronic mail if the lookup server failed. The primary motivation for having the "mail" node is to allow this sort of out-of-band notification of error conditions, as the user might otherwise be unaware of any problem.
図27は、非シグナリング動作を示す図です。ルックアップサーバが失敗した場合は特に、電子メールでユーザーに警告します。 「メール」のノードを持つための主な動機は、ユーザーがそれ以外の場合はすべての問題を認識しない場合がありますように、エラー条件のアウトオブバンド通知のこの種をできるようにすることです。
<?xml version="1.0" encoding="UTF-8"?> <cpl xmlns="urn:ietf:params:xml:ns:cpl" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="urn:ietf:params:xml:ns:cpl cpl.xsd "> <incoming> <lookup source="http://www.example.com/cgi-bin/locate.cgi?user=mary" timeout="8"> <success> <proxy/> </success> <failure> <mail url="mailto:mary@example.com?subject=Lookup%20failed"/> </failure> </lookup> </incoming> </cpl>
<？xml version = "1.0" エンコード= "UTF-8"？> <CPLののxmlns = "壷：IETF：のparams：XML：NS：CPL" のxmlns：XSI = "http://www.w3.org/2001 / XMLスキーマ・インスタンス "のxsi：のschemaLocation =" URN：IETF：paramsは：XML：NS：CPL cpl.xsd "> <着信> <ルックアップ・ソース=" http://www.example.com/cgi-bin/locate。 CGIユーザー=メアリー」タイムアウト= "8"> <成功> <プロキシ/> </成功> <失敗> <メールURL = "mailtoの：？？mary@example.com対象=ルック％20failed" /> </失敗> </参照> </入> </ 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" エンコード= "UTF-8"？> <XS：スキーマのtargetNamespace = "http://www.example.com/distinctive-ring" のxmlns = "http://www.example.com /独特のリング "の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 = "資格" attributeFormDefault = "非修飾"> <XS：インポートの名前空間= "壷：IETF：のparams：XML：NS：CPL" のschemaLocation = "cpl.xsd" / > <XS：complexTypeの名前= "DRingAction"> <XS：complexContentを> <XS：増設ベース= "CPL：ACTIONTYPE"> <XS：属性名= "ringstyle" タイプ= "XS：文字列" 使用= "オプション" / > </ XS：拡張> </ XS：complexContentを> </ XS：complexTypeの> <XS：要素名= "リング" タイプ= "DRingAction" のsubstitutionGroup = "CPL：アクション" /> </ XS：スキーマ>
<?xml version="1.0" encoding="UTF-8"?> <cpl xmlns="urn:ietf:params:xml:ns:cpl" xmlns:dr="http://www.example.com/distinctive-ring" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="urn:ietf:params:xml:ns:cpl cpl.xsd http://www.example.com/distinctive-ring distinctive-ring.xsd"> <incoming> <address-switch field="origin"> <address is="sip:boss@example.com"> <dr:ring ringstyle="warble"/> </address> </address-switch> </incoming> </cpl>
<？xml version = "1.0" エンコード= "UTF-8"？> <CPLのxmlns = "壷：IETF：のparams：XML：NS：CPL" のxmlns：DR = "http://www.example.com/distinctive http://www.w3.org/2001/XMLSchema-instance "XSI：のschemaLocation = "壷：IETF：のparams：XML：NS：CPL cpl.xsdます。http：//www.example：" XSI =のxmlns" を-ring .COM /独特リング独特-ring.xsd "> <着信> <アドレス・スイッチ・フィールド=" オリジン "> <アドレス=である" SIP：boss@example.com "> <DR：リングringstyleは=" "さえずり/ > </アドレス> </アドレススイッチ> </着信> </ 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の例では、正規表現の一致を可能にするために、アドレススイッチの仮想的な新しい属性を実装しています。これは、標準の「住所」ノードの新しい属性「正規表現」を定義します。
<?xml version="1.0" encoding="UTF-8"?> <cpl xmlns="urn:ietf:params:xml:ns:cpl" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="urn:ietf:params:xml:ns:cpl cpl.xsd "> <incoming> <address-switch field="origin" subfield="user" xmlns:re="http://www.example.com/regex"> <address re:regex="(.*.smith|.*.jones)"> <reject status="reject" reason="I don't want to talk to Smiths or Joneses"/> </address> </address-switch> </incoming> </cpl>
<？xml version = "1.0" エンコード= "UTF-8"？> <CPLののxmlns = "壷：IETF：のparams：XML：NS：CPL" のxmlns：XSI = "http://www.w3.org/2001 / XMLスキーマ・インスタンス "のxsi：のschemaLocation = "URN：IETF：paramsは：XML：NS：CPL cpl.xsd "> <着信> <アドレス・スイッチ・フィールド=" オリジン" サブフィールド= "ユーザー" のxmlns：=再" HTTP： //www.example.com/regex "> <アドレス再：正規表現="（。。。。*スミス| *・ジョーンズ）私はスミスに話をしたくない "> <拒否状態=" 拒否 "=理由"または幸せがおカネで買えるワケ "/> </アドレス> </アドレス・スイッチ> </入> </ CPL>
Figure 29: Example Script: Hypothetical Regular-Expression Extension
図29：スクリプト例：仮説的な正規表現の拡張
Finally, Figure 30 is a complex example which shows the sort of sophisticated behavior that can be achieved by combining CPL nodes. In this case, the user attempts to have his calls reach his desk; if he does not answer within a small amount of time, calls from his boss are forwarded to his mobile phone, and all other calls are directed to voicemail. If the call setup failed, no operation is specified, so the server's default behavior is performed.
最後に、図30は、CPLノードを組み合わせることによって達成することができる洗練された行動の種類を示す複雑な例です。この場合、ユーザーは自分のコールが自分の机に到達持ってしようとします。彼は時間の少ない内応答しない場合、上司からの電話は自分の携帯電話に転送され、他のすべての呼び出しがボイスメールに向けられています。コールセットアップが失敗した場合は、何も操作が指定されていないため、サーバーのデフォルトの動作が行われます。
<?xml version="1.0" encoding="UTF-8"?> <cpl xmlns="urn:ietf:params:xml:ns:cpl" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="urn:ietf:params:xml:ns:cpl cpl.xsd "> <subaction id="voicemail"> <location url="sip:jones@voicemail.example.com"> <redirect /> </location> </subaction> <incoming> <location url="sip:jones@phone.example.com"> <proxy timeout="8"> <busy> <sub ref="voicemail" /> </busy> <noanswer> <address-switch field="origin"> <address is="sip:boss@example.com"> <location url="tel:+19175551212"> <proxy /> </location> </address> <otherwise> <sub ref="voicemail" /> </otherwise> </address-switch> </noanswer> </proxy> </location> </incoming> </cpl>
<？xml version = "1.0" エンコード= "UTF-8"？> <CPLののxmlns = "壷：IETF：のparams：XML：NS：CPL" のxmlns：XSI = "http://www.w3.org/2001 / XMLスキーマ・インスタンス」のxsi：のschemaLocation = "URN：IETF：paramsは：XML：NS：> jones@voicemail.example.com "：CPLは "> <サブアクションID =" ボイスメール"> <場所のURL =" SIPをcpl.xsd <リダイレクト/> </場所> </サブアクション> <着信> <場所のURL = "SIP：jones@phone.example.com"> <プロキシタイムアウト= "8"> <ビジー> <サブREF = "ボイスメール" / > </忙しい> <noanswer> <アドレス・スイッチフィールド= "起源"> <アドレスです= "SIP：boss@example.com"> <場所のURL = "TEL：19175551212"> <プロキシ/> </場所> </アドレス> <そうでない> <サブREF = "ボイスメール" /> </さもなければ> </アドレススイッチ> </ noanswer> </プロキシ> </場所> </着信> </ CPL>
Figure 30: Example Script: A Complex Example
図30：スクリプト例：複雑な例
CPL is designed to allow services to be specified in a manner which prevents potentially hostile or mis-configured scripts from launching security attacks, including denial-of-service attacks. Because script runtime is strictly bounded by acyclicity, and because the number of possible script operations are strictly limited, scripts should not be able to inflict damage upon a CPL server.
CPLは、サービスは、サービス拒否攻撃などのセキュリティ攻撃を、起動から潜在的に敵対的な防止や誤設定されたスクリプトの方法で指定することができるように設計されています。スクリプトランタイムを厳密に非巡回で囲まれているので可能なスクリプト操作の数は厳しく制限されているため、そして、スクリプトはCPLサーバー上にダメージを与えることはできないはずです。
Because scripts can direct users' telephone calls, the method by which scripts are transmitted from a client to a server MUST be strongly authenticated. Such a method is not specified in this document.
スクリプトは、ユーザーの電話を指示することができますので、スクリプトがクライアントからサーバに送信される方法を強く認証される必要があります。このような方法は、この文書で指定されていません。
Script servers SHOULD allow server administrators to control the details of what CPL operations are permitted.
スクリプトのサーバーは、サーバー管理者は、CPLの操作が許可されているかの詳細を制御できるようにする必要があります。
This document registers a new MIME type, application/cpl+xml, and a new URN per RFC 2141 [12], RFC 2648 [13], and RFC 3688 [14].
この文書は、新しいMIMEタイプ、アプリケーション/ CPL + XML、およびRFC 2141 [12]あたりの新しいURN、RFC 2648 [13]、およびRFC 3688 [14]を登録します。
The XML namespace urn:ietf:params:xml:ns:cpl will only refer to the version of CPL in this document and will not change. Any CPL enhancements MUST be made by extensions and MUST have different namespaces.
XML名前空間URN：IETF：のparams：XML：NS：CPLは唯一このドキュメントでCPLのバージョンを参照し、変更されません。どれCPLの強化拡張によってなされなければならないと異なる名前空間を持たなければなりません。
URI: urn:ietf:params:xml:ns:cpl
URI：URN：IETF：のparams：XML：NS：CPL
Registrant Contact: Jonathan Lennox <lennox@cs.columbia.edu> Xiaotao Wu <xiaotaow@cs.columbia.edu> Henning Schulzrinne <hgs@cs.columbia.edu>
登録者連絡先：<。Huaguoshan .Columbiaこの時間制限@>ジョナサンレノックス<。レノックス@ .Columbiaこの時間制限> AOディアンW Uξ<。アモイネットワーク@この時点で.Columbia少量>ヘニング・シュルツの日も
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
<H1>コール処理言語のための名前空間</ H1> <H2> URN：IETF：のparams：XML：NS：CPL </ H2> <P> <のhref = "ftp://ftp.rfc-editor.org/中・ノートRFC3880する</a> / rfc3880.txt ">。</ P> </ body> </ html>このEND
This specification registers XML Schema for CPL, as per the guidelines in [14].
この仕様は、[14]のガイドラインに従って、CPLのためのXMLスキーマを登録します。
URI: urn:ietf:params:xml:schema:cpl
URI：URN：IETF：のparams：XML：スキーマ：CPL
Registrant contact: Jonathan Lennox <lennox@cs.columbia.edu> Xiaotao Wu <xiaotaow@cs.columbia.edu> Henning Schulzrinne <hgs@cs.columbia.edu>
登録者連絡先：<。Huaguoshan .Columbiaこの時間制限@>ジョナサンレノックス<。レノックス@ .Columbiaこの時間制限> AOディアンW Uξ<。アモイネットワーク@この時点で.Columbia少量>ヘニング・シュルツの日も
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メディアタイプ名：application
MIME subtype name: cpl+xml
MIMEサブタイプ名：CPL + xmlの
Mandatory parameters: none
必須パラメータ：なし
Optional parameters: charset As for application/xml in RFC 3023.
オプションのパラメータ：RFC 3023でアプリケーション/ XML用として文字セット。
Encoding considerations: As for application/xml in RFC 3023.
エンコードの考慮事項：RFC 3023でアプリケーション/ XMLのよう。
Security considerations: See Section 13, and Section 10 of RFC 3023.
セキュリティの考慮事項：第13節、およびRFC 3023のセクション10を参照してください。
Interoperability considerations: Different CPL servers may use incompatible address types. However, all potential interoperability issues should be resolvable at the time a script is uploaded; there should be no interoperability issues which cannot be detected until runtime.
相互運用性に関する注意事項：異なる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のファイルタイプコード：「TEXT」
Person and e-mail address for further information: Jonathan Lennox <lennox@cs.columbia.edu> Xiaotao Wu <xiaotaow@cs.columbia.edu> Henning Schulzrinne <hgs@cs.columbia.edu>
詳細については、人と電子メールアドレス：ジョナサン・レノックス<lennox@cs.columbia.edu> Xiaotao呉<xiaotaow@cs.columbia.edu>ヘニングSchulzrinneと<hgs@cs.columbia.edu>
Intended usage: COMMON
意図している用法：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.
発信コールスクリーニングスクリプトはケニー・ホムによって書かれました。
Paul E. Jones contributed greatly to the mappings of H.323 addresses.
ポールE.ジョーンズは、H.323アドレスのマッピングに大きく貢献しました。
The text of the time-switch section was taken (lightly modified) from RFC 2445 [8], by Frank Dawson and Derik Stenerson.
タイムスイッチ部のテキストは、フランク・ドーソンとDerik Stenersonにより、[8] RFC 2445から（軽く修飾）しました。
We drew a good deal of inspiration, notably the language's lack of Turing-completeness and the syntax of string matching, from the specification of Sieve [22], a language for user filtering of electronic mail messages.
私たちは、ふるい[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.
リチャード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.タイムスイッチのタイムゾーンで、コールの時間を計算します。
3. If the call time is less than "duration" after dtstart, succeed MATCH.
3.通話時間はDTSTART後、「期間」に満たない場合は、MATCHを成功します。
4. Determine the smallest unit specified in a "byxxx" rule or by the "freq." Call this the Minimum Unit. Determine the previous instant (before or equal to the call time) when all the time units smaller than the minimum unit are the same as those of "dtstart." If the minimum unit is a second, this time is the same as the instant. If the minimum unit is a minute or an hour, the minutes or the minutes and hours, respectively, must be the same as "dtstart". For all other minimum units, the time-of-day must be the same as "dtstart." If the minimum unit is a week, the day-of-the-week must be the same as "dtstart." If the minimum unit is a month, the day-of-the-month must be the same as "dtstart." If the minimum unit is a year, the month and day-of-month must both be the same as "dtstart." (Note that this means it may be necessary to roll back more than one minimum unit -- if the minimum unit is a month, then some months do not have a 31st (or 30th or 29th) day; if the minimum unit is a year, then some years do not have a February 29th. In the Gregorian calendar, it is never necessary to roll back more than two months if the minimum unit is a month, or eight years if the minimum unit is a year. Between 1904 and 2096, it is never necessary to roll back more than four years -- the eight-year rollback can only occur when the Gregorian calendar "skips" a leap year.
4.「byxxx」ルールまたはで指定された最小単位を決定し、「FREQ」をこの最小単位を呼び出します。以前の瞬間を決定する（前または通話時間に等しい）最小単位よりも小さいすべての時間単位がのものと同じである場合、「DTSTART。」最小単位は秒である場合、この時間は、インスタントと同じです。最小単位は分または時間である場合、数分または数分と時間は、それぞれ、「DTSTART」と同じでなければなりません。他のすべての最小単位の場合は、時刻は同じでなければなりません「DTSTART。」最小単位が週の場合は、曜日が同じでなければなりません「DTSTART。」最小単位が月の場合は、その日の - 月と同じでなければならない「DTSTART。」最小単位が年の場合は、月と日のヶ月は、両方のと同じでなければならない「DTSTART。」 （これは、バックつ以上の最小単位をロールバックする必要があるかもしれ意味することに注意してください - 最小単位が月の場合は、その後、いくつかのヶ月は31日（または30日または29日）の日を持っていませんが、最小単位が年の場合、その後、何年かは、2月29日を持っていません。グレゴリオ暦では、最小単位は、最小単位が年の場合は8年の月である場合、または2ヶ月以上をロールバックすることは決して必要である。1904年と2096年の間に、4年以上にロールバックするために必要なことはありません - グレゴリオ暦はうるう年「スキップ」とき8年間のロールバックにのみ発生する可能性があります。
Call this instant the Candidate Start Time.
候補開始時間、この瞬間を呼び出します。
5. If the time between the candidate start time and the call time is more than the duration, fail NOMATCH.
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.候補開始した場合の時間は、後に再発のパラメータ「まで」、（または「まで」の仮想オフライン「カウント」から計算された）失敗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.
ルール「byxxx」すべての8.は、候補者が時間を開始すると、その「byxxx」ルールで指定されたオプションのいずれかと一致していることを確認します。もしそうなら、MATCHを成功します。
9. Calculate a previous candidate start time. Repeat until the difference between the candidate start time and the call time is more than the duration. If no candidate start time has been validated, fail NOMATCH.
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 [16]にCPLの提案使用方法を提供します。 H.323を開発したITUの研究グループ16は、そのプロトコルの公式CPLのマッピング上で動作することを提案しています。したがって、このセクションは規範的ではありません。
B.1. Usage of "address-switch" with H.323
B.1。 H.323と「アドレス・スイッチ」の使い方
Address switches are specified in Section 4.1. This section specifies the mapping between H.323 messages and the fields and subfields of address-switches.
アドレススイッチは、セクション4.1で指定されています。このセクションでは、H.323メッセージとフィールドとアドレス・スイッチのサブフィールドの間のマッピングを指定します。
For H.323, the "origin" address corresponds to the alias addresses in the "sourceAddress" field of the "Setup-UUIE" user-user information element, and to the Q.931 [23] information element "Calling party number." If both fields are present, or if multiple alias addresses for "sourceAddress" are present, which one has priority is a matter of local server policy; the server SHOULD use the same resolution as it would use for routing decisions in this case. Similarly, the "destination" address corresponds to the alias addresses of the "destinationAddress" field, and to the Q.931 information element "Called party number."
H.323については、「発信元」アドレスは、「セットアップ-UUIE」ユーザ・ユーザ情報要素の「sourceAddress」フィールドにエイリアスアドレスに対応し、Q.931へ[23]情報要素「発番号。 "両方のフィールドが存在している場合、または「sourceAddress」のために複数のエイリアスアドレスは、存在する場合、どちらの優先順位は、ローカルサーバーのポリシーの問題であり、それがこのケースで意思決定をルーティングするために使用すると、サーバーは、同じ解像度を使用すべきです。同様に、「宛先」アドレスは、「宛先アドレス」フィールドのエイリアスアドレスに対応し、Q.931情報要素に「着番号。」
The "original-destination" address corresponds to the "Redirecting number" Q.931 information element, if it is present; otherwise it is the same as the "destination" address.
それが存在する場合、「元の宛先」アドレスは、「リダイレクト数」Q.931情報要素に対応します。それ以外の場合は、「宛先」アドレスと同じです。
The mapping of H.323 addresses into subfields depends on the type of the alias address. An additional subfield type, "alias-type", is defined for H.323 servers, corresponding to the type of the address. Possible values are "dialedDigits", "h323-ID", "url-ID", "transportID", "email-ID", "partyNumber", "mobileUIM", and "Q.931IE". If future versions of the H.323 specification define additional types of alias addresses, those names MAY also be used.
サブフィールドにH.323アドレスのマッピングは、エイリアスアドレスの種類に依存します。追加のサブフィールドのタイプ、「エイリアス型」は、アドレスの種類に対応し、H.323サーバのために定義されています。可能な値は、 "あるdialedDigits"、 "H323-ID"、 "URL-ID"、 "transportID"、 "電子メールID"、 "partyNumber"、 "mobileUIM"、および "Q.931IE" です。 H.323仕様の将来のバージョンでは、エイリアスアドレスの追加のタイプを定義する場合、それらの名前を使用することもできます。
In versions of H.323 prior to version 4, "dialedDigits" was known as "e164". The two names SHOULD be treated as synonyms.
前バージョン4 H.323のバージョンでは、「あるdialedDigits」が「E164」として知られていました。 2人の名前が同義語として扱われるべきです。
The value of the "address-type" subfield for H.323 messages is "h323" unless the alias type is "url-ID" and the URL scheme is something other than h323; in this case the address-type is the URL scheme, as specified in Section 4.1.1 for SIP.
エイリアスタイプは「URL-ID」で、URLスキームはH323以外のものでない限り、H.323メッセージの値が「アドレス型」のサブフィールドは、「H323」です。 SIPについては、セクション4.1.1に指定されている。この場合、アドレス型は、URLスキームです。
An H.323-aware CPL server SHOULD map the address subfields from the primary alias used for routing. It MAY also map subfields from other aliases, if subfields in the primary address are not present.
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」と「ユーザ」サブフィールドは、数字の文字列です。 「ホスト」と「ポート」サブフィールドは存在しません。
url-ID: the same mappings are used as for SIP, in Section 4.1.1.
URL-ID：同じマッピングは、4.1.1項では、SIP用として使用されています。
h323-ID: the "user" field is the string of characters, as is the "entire-address" form. All other subfields are not present.
H323-IDは：「全体のアドレス」の形式であるとして「ユーザー」フィールドには、文字の文字列です。他のすべてのサブフィールドは存在しません。
email-ID: the "user" and "host" subfields are set to the corresponding parts of the e-mail address. The "port" and "tel" subfields are not present. The "entire-address" form corresponds to the entire e-mail address.
電子メールIDは：「ユーザー」と「ホスト」のサブフィールドは、メールアドレスの対応する部分に設定されています。 「ポート」と「TEL」サブフィールドは存在しません。 「全体のアドレス」フォームには、全体の電子メールアドレスに対応しています。
transportID: if the TransportAddress is of type "ipAddress," "ipSourceRoute," or "ip6Address," the "host" subfield is set to the "ip" element of the sequence, translated into the standard IPv4 or IPv6 textual representation, and the "port" subfield is set to the "port" element of the sequence represented in decimal. The "tel" and "user" fields are not present. The "entire-address" form is not defined. The representation and mapping of transport addresses is not defined for non-IP addresses.
標準IPv4またはIPv6のテキスト表現に翻訳TransportAddressタイプである場合、「ipAddressの」、「ipSourceRoute」または「ip6Address」、「ホスト配列のIP」要素「サブフィールドに設定されている」、と：transportID 「ポート」サブフィールドは小数で表される配列の「ポート」の要素に設定されています。 「TEL」と「ユーザー」のフィールドは存在しません。 「全体のアドレス」の形式が定義されていません。表現とトランスポートアドレスのマッピングは、非IPアドレスのために定義されていません。
H.323 [16] defines an "h323" URI scheme. This appendix defines a mapping for these URIs onto the CPL "address-switch" subfields, as given in Section 4.1. This definition is also available as RFC 3508 [24], which is an excerpt from the H.323 specification.
H.323 [16] "H323" URIスキームを定義します。 4.1節で与えられたように、この付録では、CPL「アドレススイッチ」のサブフィールド上にこれらのURIのマッピングを定義します。この定義はまた、H.323仕様からの抜粋であるRFC 3508 [24]として利用可能です。
For h323 URIs, the "user", "host", and "port" subfields are set to the corresponding parts of the H.323 URL. The "tel" subfield is not present. The "entire-address" form corresponds to the entire URI.
H323のURIについては、「ユーザー」、「ホスト」、および「ポート」サブフィールドは、H.323のURLの対応する部分に設定されています。 「TEL」サブフィールドは存在しません。 「全体のアドレス」フォームには、全体のURIに対応しています。
This mapping MAY be used both for h323 URIs in an h323 "url-ID" address alias, and for h323 URIs in SIP messages.
このマッピングは、両方のH323でH323のURI「URL-ID」アドレスの別名のため、およびSIPメッセージ内H323 URIのために使用されるかもしれません。
B.2. Usage of "string-switch" with H.323
B.2。 H.323と「文字列スイッチ」の使い方
For H.323, the "string-switch" node (see Section 4.2) is used as follows. The field "display" corresponds to the Q.931 information element of the same name, copied verbatim. The fields "subject", "organization", and "user-agent" are not used and are never present.
次のように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）は、メッセージ・レベルの情報要素ではなく、アドレスレベル1、およびb）Q.931仕様[23] [t]が表示情報要素の彼の目的は、ディスプレイを供給することであるのみ」と言うありますユーザーが表示することができる情報は、代わりに文字列スイッチ 『」にマッチできるようにするために、より適切であると考えられます』。
B.3. Usage of "language-switch" with H.323
B.3。 H.323と「言語切り替え」の使い方
The language-ranges for the "language-switch" switch are obtained from the H.323 UUIE "language". The switch is not-present if the initial message did not contain this UUIE.
「言語切り替え」スイッチ用の言語の範囲は、H.323 UUIE「言語」から取得されます。最初のメッセージがこのUUIEを含んでいなかった場合、スイッチは、存在しません。
B.4. Usage of "priority-switch" with H.323
B.4。 H.323と「優先スイッチ」の使い方
All H.323 messages are considered to have priority "normal" for the purpose of a priority switch (see Section 4.5).
すべてのH.323メッセージは（4.5節を参照）優先スイッチの目的のために、「通常」の優先度を有すると考えられます。
B.5. Usage of "location" with H.323
B.5。 H.323と「場所」の使い方
Locations in explicit location nodes (Section 5.1) are specified as URLs. Therefore, all locations added in this manner are interpreted as being of alias type "url-ID" in H.323.
明示的な位置ノード（セクション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を参照）。
B.6. Usage of "lookup" with H.323
B.6。 H.323での「検索」の使い方
For location lookup nodes (Section 5.2), the "registration" lookup source corresponds to the locations registered with the server using "RAS" messages.
位置検索ノード（セクション5.2）のために、「登録」参照ソースが「RAS」メッセージを使用してサーバに登録場所に対応します。
B.7. Usage of "remove-location" with H.323
B.7。 H.323と「削除-場所」の使い方
Location removal nodes (Section 5.3) remove addresses with the alias type "url-ID" using verbatim string matching on the URLs. If a "tel" URL is specified as the location, matching addresses (ignoring visual separators) with the alias types "dialedDigits" ("e164"), "partyNumber", "mobileUIM", or "Q.931IE" are also removed. No mechanism is provided to remove other alias types.
場所除去ノード（5.3節）エイリアスタイプ「URL-ID」のURLにマッチする逐語的文字列を使用してアドレスを削除してください。 「TEL」URLは、「partyNumberは」エイリアスタイプ「あるdialedDigits」（「E164」）とアドレス（視覚セパレータを無視）と一致する、場所として指定されている場合、「mobileUIM」、または「Q.931IE」も除去されます。いかなるメカニズムは他の別名型を削除するために提供されていません。
C. The XML Schema for CPL
CPLのためのC.ザ・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」ののsubstitutionGroupとして定義されます。すべてのスイッチは「スイッチ」要素ののsubstitutionGroupとして定義されています。すべてのアクションは「アクション」要素ののsubstitutionGroupとして定義されています。
+---------+ +------+ +--address
+-+ancillary| |switch|** +--------------+ | +-not-present
| +---------+ +---+--+ **|address-switch+-+-+-address
| | * +--------------+ +--otherwise
| +---------+ +----+ | * +--language
+-+subaction+-+Node| | * +---------------+ | +-not-present
| +---------+ +----+ | **|language-switch|-+-+-language
| | * +---------------+ +--otherwise
| | * +--priority
| | * +---------------+ | +-not-present
| | **|priority-switch|-+-+-priority
| | * +---------------+ +--otherwise
| | * +--string
cpl-+ | * +-------------+ | +-not-present
| | **|string-switch|-+ +-string
| | * +-------------+ +--otherwise
| | * +--time
| +--------------+ +-+--+ * +-----------+ | +-not-present
+-+toplevelaction+-+Node| *|time-switch|-+-+-time
+-----*--------+ +-+--+ +-----------+ +--otherwise
* | +--------+ +----+
* | **|location+-|Node|
* | +--------+ * +--------+ +----+
* +--------+ |-+modifier|** +------+ +-success-Node
**|incoming| | +--------+ *-|lookup+-+-notfound-Node
* +--------+ | * +------+ +-failure-Node
* | +---+ * +---------------+ +----+
* +--------+ +-+Sub+-sub **|remove-location+-+Node|
*|outgoing| | +---+ +---------------+ +----+
+--------+ | +---+
| **|log+-Node
| * +---+
| * +----+
| +------+ **|mail+-Node
+-+action|** +----+ +-busy-Node
---- contains +------+ * +-----+ |
**|proxy+----+-noanswer-Node
**** substitutes * +-----+ |
* +--------+ +-failure-Node
**|redirect| |
* +--------+ +-redirection-Node
* +------+ |
*|reject| +-default-Node
+------+
Figure 31: The structure of the XML schema for CPL
図31：CPLのためのXMLスキーマの構造
BEGIN <?xml version="1.0" encoding="UTF-8"?> <xs:schema targetNamespace="urn:ietf:params:xml:ns:cpl" xmlns="urn:ietf:params:xml:ns:cpl" xmlns:xs="http://www.w3.org/2001/XMLSchema" elementFormDefault="qualified" attributeFormDefault="unqualified"> <xs:complexType name="TopLevelActionType" abstract="true"> <xs:group ref="Node"/> </xs:complexType> <xs:element name="toplevelaction" type="TopLevelActionType"/> <xs:complexType name="ActionType" abstract="true"/> <xs:element name="action" type="ActionType"/> <xs:complexType name="SwitchType" abstract="true"/> <xs:element name="switch" type="SwitchType"/> <xs:complexType name="ModifierType" abstract="true"/> <xs:element name="modifier" type="ModifierType"/> <xs:element name="location" type="LocationType" substitutionGroup="modifier"/> <xs:element name="lookup" type="LookupType" substitutionGroup="modifier"/> <xs:element name="remove-location" type="RemoveLocationType" substitutionGroup="modifier"/> <xs:element name="sub" type="SubAction"/> <xs:group name="Node"> <xs:choice> <xs:element ref="switch" minOccurs="0" maxOccurs="1"/> <xs:element ref="modifier" minOccurs="0" maxOccurs="1"/> <xs:element ref="sub" minOccurs="0" maxOccurs="1"/> <xs:element ref="action" minOccurs="0" maxOccurs="1"/> </xs:choice> </xs:group> <xs:complexType name="OtherwiseAction"> <xs:group ref="Node"/> </xs:complexType> <xs:complexType name="NotPresentAction"> <xs:group ref="Node"/> </xs:complexType> <xs:simpleType name="YesNoType"> <xs:restriction base="xs:NMTOKEN"> <xs:enumeration value="yes"/> <xs:enumeration value="no"/> </xs:restriction> </xs:simpleType> <xs:simpleType name="StatusType"> <xs:union> <xs:simpleType> <xs:restriction base="xs:NMTOKEN">
BEGIN <XS <xmlのバージョン= "1.0" エンコード= "UTF-8"？>：スキーマのtargetNamespace = "壷：IETF：のparams：XML：NS：CPL"：IETF：のparams：XML：NS = "壷のxmlnsを： CPL」のxmlns：XS = "http://www.w3.org/2001/XMLSchema" のelementFormDefault = "資格" attributeFormDefault = "非修飾"> <XS：complexTypeの名= "TopLevelActionType" 抽象= "真"> <XS：グループREF = "ノード" /> </ XS：complexTypeの> <XS：要素名= "toplevelaction" タイプ= "TopLevelActionType" /> <XS：complexTypeの名= "ACTIONTYPE" 抽象= "真" /> <XS：要素名= "アクション" タイプ= "ACTIONTYPE" /> <XS：complexTypeの名= "SWITCHTYPE" 抽象= "真" /> <XS：要素名= "スイッチ" タイプ= "SWITCHTYPE" /> <XS：complexTypeの名= "ModifierType" 抽象= "TRUE" /> <XS：要素名= "修飾語" TYPE = "ModifierType" /> <XS：要素名= "位置" タイプ= "LocationType" のsubstitutionGroup = "改質" /> <XS：要素名= "ルックアップ" タイプ= "LookupType" のsubstitutionGroup = "改質" /> <XS：要素名= "削除ロケーションを" TYPE = "RemoveLocationType" のsubstitutionGroup = "改質" /> <XS：要素名= "サブ"タイプ= "サブアクション" /> <XS ：グループ名= "ノード"> <XS：選択> <XS：要素REF = "スイッチ" のminOccurs = "0" のmaxOccurs = "1" /> <XS：要素REF = "改質" のminOccurs = "0" のmaxOccurs = "1" /> <XS：要素REF = "サブ" のminOccurs = "0" のmaxOccurs = "1" /> <XS：要素REF = "アクション" のminOccurs = "0" のmaxOccurs = "1" /> </ XS ：選択> </ XS：グループ> <XS：complexTypeの名= "OtherwiseAction"> <XS：グループREF = "ノード" /> </ XS：complexTypeの> <XS：complexTypeの名= "NotPresentAction"> <XS：グループREF = "ノード" /> </ XS：complexTypeの> <XS：単純型名= "YesNoType"> <XS：制限ベース= "XS：NMTOKEN"> <XS：列挙値= "はい" /> <XS：列挙値= "NO" /> </ XS：制限> </ XS：単純> <XS：単純型名= "StatusType"> <XS：組合> <XS：単純> <XS：制限ベース= "XS：NMTOKEN" >
<xs:enumeration value="busy"/> <xs:enumeration value="notfound"/> <xs:enumeration value="reject"/> <xs:enumeration value="error"/> </xs:restriction> </xs:simpleType> <xs:simpleType> <xs:restriction base="xs:string"/> </xs:simpleType> </xs:union> </xs:simpleType> <xs:simpleType name="OrderingType"> <xs:restriction base="xs:NMTOKEN"> <xs:enumeration value="parallel"/> <xs:enumeration value="sequential"/> <xs:enumeration value="first-only"/> </xs:restriction> </xs:simpleType> <xs:simpleType name="AddressFieldType"> <xs:union> <xs:simpleType> <xs:restriction base="xs:NMTOKEN"> <xs:enumeration value="origin"/> <xs:enumeration value="destination"/> <xs:enumeration value="original-destination"/> </xs:restriction> </xs:simpleType> <xs:simpleType> <xs:restriction base="xs:string"/> </xs:simpleType> </xs:union> </xs:simpleType> <xs:simpleType name="AddressSubfieldType"> <xs:union> <xs:simpleType> <xs:restriction base="xs:NMTOKEN"> <xs:enumeration value="address-type"/> <xs:enumeration value="user"/> <xs:enumeration value="host"/> <xs:enumeration value="port"/> <xs:enumeration value="tel"/> <xs:enumeration value="display"/> <xs:enumeration value="password"/> <xs:enumeration value="alias-type"/> </xs:restriction> </xs:simpleType>
<XS：列挙値= "ビジー" /> <XS：列挙値= "NOTFOUND" /> <XS：列挙値= "拒否" /> <XS：列挙値= "エラー" /> </ XS：制限> </ XS：単純> <XS：単純> <XS：制限ベース= "XS：文字列" /> </ XS：単純> </ XS：組合> </ XS：単純> <XS：単純型名= "OrderingType "> <XS：制限ベース=" XS：NMTOKEN "> <XS：列挙値=" 平行 "/> <XS：列挙値=" シーケンシャル "/> <XS：列挙値=" 最初のみ "/> < / XS：制限> </ XS：単純> <XS：単純型名= "AddressFieldType"> <XS：組合> <XS：単純> <XS：制限ベース= "XS：NMTOKEN"> <XS：列挙値=」原点 "/> <XS：列挙値=" 宛先 "/> <XS：列挙値=" オリジナル先 "/> </ XS：制限> </ XS：単純> <XS：単純> <XS：制限ベース= "XS：文字列" /> </ XS：単純> </ XS：組合> </ XS：単純> <XS：単純型名= "AddressSubfieldType"> <XS：組合> <XS：単純> <XS：制限基地= "XS：NMTOKEN"> <XS：列挙値= "アドレスタイプ" /> <XS：列挙値=「使用R "/> <XS：列挙値=" ホスト "/> <XS：列挙値=" ポート "/> <XS：列挙値=" TEL "/> <XS：列挙値=" 表示 "/> <XS ：列挙値= "パスワード" /> <XS：列挙値= "エイリアス型" /> </ XS：制限> </ XS：simpleTypeの>
<xs:simpleType> <xs:restriction base="xs:string"/> </xs:simpleType> </xs:union> </xs:simpleType> <xs:complexType name="AddressType"> <xs:annotation> <xs:documentation>Exactly one of the three attributes must appear</xs:documentation> </xs:annotation> <xs:group ref="Node"/> <xs:attribute name="is" type="xs:string" use="optional"/> <xs:attribute name="contains" type="xs:string" use="optional"> <xs:annotation> <xs:documentation>for "display" only</xs:documentation> </xs:annotation> </xs:attribute> <xs:attribute name="subdomain-of" type="xs:string" use="optional"> <xs:annotation> <xs:documentation>for "host", "tel" only</xs:documentation> </xs:annotation> </xs:attribute> <xs:anyAttribute namespace="##any" processContents="lax"/> </xs:complexType> <xs:complexType name="AddressSwitchType"> <xs:complexContent> <xs:extension base="SwitchType"> <xs:sequence> <xs:element name="address" type="AddressType" minOccurs="0" maxOccurs="unbounded"/> <xs:sequence minOccurs="0"> <xs:element name="not-present" type="NotPresentAction"/> <xs:element name="address" type="AddressType" minOccurs="0" maxOccurs="unbounded"/> </xs:sequence> <xs:element name="otherwise" type="OtherwiseAction" minOccurs="0"/> </xs:sequence> <xs:attribute name="field" type="AddressFieldType" use="required"/> <xs:attribute name="subfield" type="AddressSubfieldType" use="optional"/> </xs:extension> </xs:complexContent> </xs:complexType> <xs:element name="address-switch" type="AddressSwitchType" substitutionGroup="switch"/>
<XS：単純> <XS：制限ベース= "XS：文字列" /> </ XS：単純> </ XS：組合> </ XS：単純> <XS：complexTypeの名= "AddressTypeに"> <XS：注釈> <XS：ドキュメント>の3つの属性のいずれか1つだけが</ XS表示される必要があります：ドキュメント> </ XS：注釈> <XS：グループREF = "ノード" /> <XS：属性名= "である" タイプ= "XS ：文字列」使用= "オプション" /> <XS：属性名は= "のみ</ XS表示 "： "のドキュメント>> <XS：：注釈> <XS" 文字列 "使用=" オプション" タイプ=" XSが含まれています：ドキュメント> </ XS：注釈> </ XS：属性> <XS：属性名= "サブドメインの" タイプ= "XS：文字列" 使用= "オプション"> <XS：注釈> <XS：ドキュメント>のために"ホスト"、 "TEL" のみ</ XS：ドキュメンテーション> </ XS：注釈> </ XS：属性> <XS：anyAttributeは名前空間= "##あらゆる" のprocessContents = "緩い" /> </ XS：complexTypeの> <XS：complexTypeの名前= "AddressSwitchType"> <XS：complexContentを> <XS：増設ベース= "SWITCHTYPE"> <XS：配列> <XS：要素名= "アドレス" タイプ= "AddressTypeに" のminOccurs = "0" maxOccurs属性XS /> <= "無制限"：シーケンスのminOccurs = "0"> <XS：要素名= "ではない-PRES ENT」タイプ= "NotPresentAction" /> <XS：要素名= "アドレス" タイプ= "AddressTypeに" のminOccurs = "0" のmaxOccurs = "無制限" /> </ XS：配列> <XS：要素名= "そうでなければ"タイプ= "OtherwiseAction" のminOccurs = "0" /> </ XS：シーケンス> <XS：属性名= "フィールド" タイプ= "AddressFieldType" 使用= "必要" /> <XS：属性名= "サブフィールド" タイプ= "AddressSubfieldType" 使用= "オプション" /> </ XS：拡張> </ XS：complexContentを> </ XS：complexTypeの> <XS：要素名= "アドレス・スイッチ" タイプ= "AddressSwitchType" のsubstitutionGroup = "スイッチ" / >
<xs:simpleType name="StringFieldType"> <xs:restriction base="xs:NMTOKEN"> <xs:enumeration value="subject"/> <xs:enumeration value="organization"/> <xs:enumeration value="user-agent"/> <xs:enumeration value="display"/> </xs:restriction> </xs:simpleType> <xs:complexType name="StringType"> <xs:group ref="Node"/> <xs:attribute name="is" type="xs:string" use="optional"/> <xs:attribute name="contains" type="xs:string" use="optional"/> <xs:anyAttribute namespace="##any" processContents="lax"/> </xs:complexType> <xs:complexType name="StringSwitchType"> <xs:complexContent> <xs:extension base="SwitchType"> <xs:sequence> <xs:element name="string" type="StringType" minOccurs="0" maxOccurs="unbounded"/> <xs:sequence minOccurs="0"> <xs:element name="not-present" type="NotPresentAction"/> <xs:element name="string" type="StringType" minOccurs="0" maxOccurs="unbounded"/> </xs:sequence> <xs:element name="otherwise" type="OtherwiseAction" minOccurs="0"/> </xs:sequence> <xs:attribute name="field" type="StringFieldType" use="required"> <xs:annotation> <xs:documentation>Strings are matched as case-insensitive Unicode strings.</xs:documentation> </xs:annotation> </xs:attribute> </xs:extension> </xs:complexContent> </xs:complexType> <xs:element name="string-switch" type="StringSwitchType" substitutionGroup="switch"/> <xs:complexType name="LanguageType"> <xs:group ref="Node"/> <xs:attribute name="matches" type="xs:string" use="required"> <xs:annotation> <xs:documentation>The value of one of these parameters is a language-tag, as defined in RFC 3066.</xs:documentation> </xs:annotation>
<XS：単純型名= "StringFieldType"> <XS：制限ベース= "XS：NMTOKEN"> <XS：列挙値= "被験者" /> <XS：列挙値= "組織" /> <XS：列挙値= "ユーザエージェント" /> <XS：列挙値= "表示" /> </ XS：制限> </ XS：単純> <XS：complexTypeの名= "StringType"> <XS：グループREF = "ノード" / > <XS：属性名= "である" タイプ= "XS：文字列" 使用= "オプション" /> <XS：属性名= "含む" タイプ= "XS：文字列" 使用= "オプション" /> <XS： anyAttributeは名前空間= "##あらゆる" のprocessContents = "緩い" /> </ XS：complexTypeの> <XS：complexTypeの名= "StringSwitchType"> <XS：complexContentを> <XS：増設ベース= "SWITCHTYPE"> <XS：シーケンス> <XS：要素名= "文字列" タイプ= "StringType" のminOccurs = "0" のmaxOccurs = "無制限" /> <XS：配列のminOccurs = "0"> <XS：要素名= "-存在しない" タイプ= "NotPresentAction" /> <XS：要素名= "文字列" タイプ= "StringType" のminOccurs = "0" のmaxOccurs = "無制限" /> </ XS：配列> <XS：要素名= "そうでなければ" タイプ= "OtherwiseAction "minOccurs属性=" 0 "/> </ XS：シーケンス> <XS：属性名=" フィールド "タイプ=" セントringFieldType」使用は= "必要"> <XS：注釈> <XS：ドキュメント>文字列は、大文字と小文字を区別しないUnicode文字列として一致している</ XS：ドキュメンテーション> </ XS：注釈> </ XS：属性> </ XS：拡張> </ XS：complexContentを> </ XS：complexTypeの> <XS：要素名= "文字列スイッチ" タイプ= "StringSwitchType" のsubstitutionGroup = "スイッチ" /> <XS：complexTypeの名前= "LanguageType"> <XS：グループREF =「ノード」/> <XS：属性名=「マッチ」タイプ=「XS：文字列」使用=> <XS「必要」：注釈が> <XS：>これらのパラメータの1つの値は、言語ドキュメントですRFC 3066で定義されて-tag、</ XS：ドキュメント>。</ XS：注釈>
</xs:attribute> <xs:anyAttribute namespace="##any" processContents="lax"/> </xs:complexType> <xs:complexType name="LanguageSwitchType"> <xs:complexContent> <xs:extension base="SwitchType"> <xs:sequence> <xs:element name="language" type="LanguageType" minOccurs="0" maxOccurs="unbounded"/> <xs:sequence minOccurs="0"> <xs:element name="not-present" type="NotPresentAction"/> <xs:element name="language" type="LanguageType" minOccurs="0" maxOccurs="unbounded"/> </xs:sequence> <xs:element name="otherwise" type="OtherwiseAction" minOccurs="0"/> </xs:sequence> </xs:extension> </xs:complexContent> </xs:complexType> <xs:element name="language-switch" type="LanguageSwitchType" substitutionGroup="switch"/> <xs:simpleType name="FreqType"> <xs:restriction base="xs:NMTOKEN"> <xs:pattern value="[s|S][e|E][c|C][o|O][n|N][d|D][l|L][y|Y]"/> <xs:pattern value="[m|M][i|I][n|N][u|U][t|T][e|E][l|L][y|Y]"/> <xs:pattern value="[h|H][o|O][u|U][r|R][l|L][y|Y]"/> <xs:pattern value="[d|D][a|A][i|I][l|L][y|Y]"/> <xs:pattern value="[w|W][e|E][e|E][k|K][l|L][y|Y]"/> <xs:pattern value="[m|M][o|N][n|N][t|T][h|H][l|L][y|Y]"/> <xs:pattern value="[y|Y][e|E][a|A][r|R][l|L][y|Y]"/> </xs:restriction> </xs:simpleType> <xs:simpleType name="YearDayType"> <xs:union> <xs:simpleType> <xs:restriction base="xs:integer"> <xs:minInclusive value="-366"/> <xs:maxInclusive value="-1"/> </xs:restriction> </xs:simpleType> <xs:simpleType> <xs:restriction base="xs:integer"> <xs:minInclusive value="1"/> <xs:maxExclusive value="366"/> </xs:restriction> </xs:simpleType> </xs:union>
</ XS：属性> <XS：anyAttributeは名前空間= "##あらゆる" のprocessContents = "緩い" /> </ XS：complexTypeの> <XS：complexTypeの名前= "LanguageSwitchType"> <XS：complexContentを> <XS：増設ベース= "SWITCHTYPE"> <XS：配列> <XS：要素名= "言語" タイプ= "LanguageType" のminOccurs = "0" のmaxOccurs = "無制限" /> <XS：配列のminOccurs = "0"> <XS：要素NAME = "-存在しない" タイプ= "NotPresentAction" /> <XS：要素名= "言語" タイプ= "LanguageType" のminOccurs = "0" のmaxOccurs = "無制限" /> </ XS：配列> <XS：要素NAME = "そうでなければ" タイプ= "OtherwiseAction" のminOccurs = "0" /> </ XS：配列> </ XS：拡張> </ XS：complexContentを> </ XS：complexTypeの> <XS：要素名= "、言語スイッチ "タイプ= "LanguageSwitchType" のsubstitutionGroup = "スイッチ"/> <XS：単純型名= "FreqType"> <XS：制限ベース= "XS：NMTOKEN"> <XS：パターン値=" [S | S] [E | E] [C | C] [O | O] [N | N] [D | D] [L | L] [Y | Y] "/> <XS：パターン値=" [M | M] [I | I] [N | N] [U | U] [T | T] [E | E] [L | L] [Y | Y] "/> <XS：パターン値=" [H | H] [O | O] [U | U] [R | R] [L | L] [Y | Y] "/> <XS：パターン値=" [D | D] [| A] [I | I] [L | L] [Y | Y] "/> <XS ：パターン値= "[W | W] [E | E] [E | E] [K | K] [L | L] [Y | Y]" /> <XS：パターン値= "[M | M] [O | N] [N | N] [T | T] [H | H] [L | L] [Y | Y] "/> <XS：パターン値=" [Y | Y] [E | E] [| A] [R | R] [L | L] [Y | Y] "/> </ XS：制限> </ XS：単純> <XS：単純型名=" YearDayType "> <XS：組合> <XS：単純> <XS：制限ベース= "XS：整数"> <XS：のminInclusive値= " - 366" /> <XS：maxInclusiveを値= " - 1" /> </ XS：制限> </ XS ：単純> <XS：単純> <XS：制限ベース= "XS：整数"> <XS：のminInclusive値= "1" /> <XS：maxExclusive値= "366" /> </ XS：制限> </ XS：単純> </ XS：組合>
</xs:simpleType> <xs:simpleType name="DayType"> <xs:restriction base="xs:NMTOKEN"> <xs:pattern value="[m|M][o|O]"/> <xs:pattern value="[t|T][u|U]"/> <xs:pattern value="[w|W][e|E]"/> <xs:pattern value="[t|T][h|H]"/> <xs:pattern value="[f|F][r|R]"/> <xs:pattern value="[s|S][a|A]"/> <xs:pattern value="[s|S][u|U]"/> </xs:restriction> </xs:simpleType> <xs:complexType name="TimeType"> <xs:annotation> <xs:documentation>Exactly one of the two attributes "dtend" and "duration" must occur. None of the attributes following freq are meaningful unless freq appears. </xs:documentation> </xs:annotation> <xs:group ref="Node"/> <xs:attribute name="dtstart" type="xs:string" use="required"> <xs:annotation> <xs:documentation>RFC 2445 DATE-TIME</xs:documentation> </xs:annotation> </xs:attribute> <xs:attribute name="dtend" type="xs:string" use="optional"> <xs:annotation> <xs:documentation>RFC 2445 DATE-TIME</xs:documentation> </xs:annotation> </xs:attribute> <xs:attribute name="duration" type="xs:string" use="optional"> <xs:annotation> <xs:documentation>RFC 2445 DURATION</xs:documentation> </xs:annotation> </xs:attribute> <xs:attribute name="freq" type="FreqType" use="optional"/> <xs:attribute name="interval" type="xs:positiveInteger" default="1"/> <xs:attribute name="until" type="xs:string" use="optional"> <xs:annotation> <xs:documentation>RFC 2445 DATE-TIME</xs:documentation> </xs:annotation> </xs:attribute> <xs:attribute name="count" type="xs:positiveInteger" use="optional"/> <xs:attribute name="bysecond" type="xs:string" use="optional"> <xs:annotation> <xs:documentation>Comma-separated list of seconds within a
</ XS：単純> <XS：単純型名= "DayType"> <XS：制限ベース= "XS：NMTOKEN"> <XS：パターン値= "[M | M] [O | O]" /> <XS ：パターン値= "[T | T] [U | U]" /> <XS：パターン値= "[W | W] [E | E]" /> <XS：パターン値= "[T | T] [H | H] "/> <XS：パターン値=" [F | F] [R | R] "/> <XS：パターン値=" [S | S] [| A] "/> <XS ：パターン値= "[S | S] [U | U]" /> </ XS：制限> </ XS：単純> <XS：complexTypeの名= "TimeType"> <XS：注釈> <XS：ドキュメント>正確に二つの属性「DTEND」と「継続」のいずれかが発生しなければなりません。 FREQが表示されない限り、FREQを次の属性のいずれも意味がありません。 </ XS：ドキュメンテーション> </ XS：注釈> <XS：グループREF = "ノード" /> <XS：注釈> <XS：：属性名= "DTSTART" タイプ= "XS文字列" 使用= "必要"> <XS：ドキュメント> RFC 2445 DATE-TIME </ XS：ドキュメンテーション> </ XS：注釈> </ XS：属性> <XS：属性名= "DTEND" タイプ= "XS：文字列" 使用= "オプション"> <XS：注釈> <XS：ドキュメント> RFC 2445 DATE-TIME </ XS：ドキュメンテーション> </ XS：注釈> </ XS：属性> <XS：属性名= "継続" タイプ= "XS：文字列" 使用= "オプション"> <XS：注釈> <XS：ドキュメント> RFC 2445 DURATION </ XS：ドキュメンテーション> </ XS：注釈> </ XS：属性> <XS：属性名= "FREQ" タイプ= "FreqType"属性名= "間隔" タイプ= "XS：：POSITIVEINTEGER" デフォルト= "1" /> <XS：属性名=タイプ= "まで" "のxs：string" が使用= "オプション= "オプション"/> <XSを使用"> <XS：注釈> <XS：ドキュメント> RFC 2445 DATE-TIME </ XS：ドキュメンテーション> </ XS：注釈> </ XS：属性> <XS：属性名=" 数 "タイプ=" XS：POSITIVEINTEGER "使う=" オプション "/> <XS：属性名=" BYSECOND」タイプ= "XS：文字列" 使用= "オプション"> <XS：注釈> <XS：ドキュメント>秒以内のカンマ区切りリスト
minute. Valid values are 0 to 59.</xs:documentation> </xs:annotation> </xs:attribute> <xs:attribute name="byminute" type="xs:string" use="optional"> <xs:annotation> <xs:documentation>Comma-separated list of minutes within an hour. Valid values are 0 to 59.</xs:documentation> </xs:annotation> </xs:attribute> <xs:attribute name="byhour" type="xs:string" use="optional"> <xs:annotation> <xs:documentation>Comma-separated list of hours of the day. Valid values are 0 to 23.</xs:documentation> </xs:annotation> </xs:attribute> <xs:attribute name="byday" type="xs:string" use="optional"> <xs:annotation> <xs:documentation>Comma-separated list of days of the week. Valid values are "MO", "TU", "WE", "TH", "FR", "SA" and "SU". These values are not case-sensitive. Each can be preceded by a positive (+n) or negative (-n) integer.</xs:documentation> </xs:annotation> </xs:attribute> <xs:attribute name="bymonthday" type="xs:string" use="optional"> <xs:annotation> <xs:documentation>Comma-separated list of days of the month. Valid values are 1 to 31 or -31 to -1.</xs:documentation> </xs:annotation> </xs:attribute> <xs:attribute name="byyearday" type="xs:string" use="optional"> <xs:annotation> <xs:documentation>Comma-separated list of days of the year. Valid values are 1 to 366 or -366 to -1.</xs:documentation> </xs:annotation> </xs:attribute> <xs:attribute name="byweekno" type="xs:string" use="optional"> <xs:annotation> <xs:documentation>Comma-separated list of ordinals specifying weeks of the year. Valid values are 1 to 53 or -53 to -1.</xs:documentation> </xs:annotation> </xs:attribute> <xs:attribute name="bymonth" type="xs:string" use="optional"> <xs:annotation> <xs:documentation>Comma-separated list of months of the year.
分。有効な値は0〜59です。</ XS：ドキュメント>。</ XS：注釈> </ XS：属性> <XS：属性名= "BYMINUTE" タイプ= "XS：文字列" 使用= "オプション"> <XS：注釈> <XS：時間以内分のドキュメント>カンマ区切りリスト。有効な値は0〜59です。</ XS：ドキュメント>。</ XS：注釈> </ XS：属性> <XS：属性名= "BYHOUR" タイプ= "XS：文字列" 使用= "オプション"> <XS：注釈> <XS：1日の時間のドキュメント>カンマ区切りリスト。有効な値は23に0をしている</ XS：ドキュメント>。</ XS：注釈> </ XS：属性> <XS：属性名= "BYDAY" タイプ= "XS：文字列" 使用= "オプション"> <XS：注釈> <XS：ドキュメント>曜日のカンマ区切りリスト。有効な値は、 "MO"、 "TU"、 "WE"、 "TH"、 "FR"、 "SA" と "SU" です。これらの値は、大文字と小文字は区別されません。それぞれは、正（+ N）または負（-n）整数が先行することができる</ XS：ドキュメント>。</ XS：注釈> </ XS：属性> <XS：属性名= "BYMONTHDAY" タイプ= "XSを：文字列」使用= 『オプション』> <XS：注釈> <XS：ドキュメント>月の日数のカンマ区切りリスト。有効な値は1から31にまたは-31 -1である。</ XS：ドキュメンテーション> </ XS：注釈> </ XS：属性> <XS：属性名は= "byyearday" タイプ= "XS：文字列" 使用=」オプション "> <XS：注釈> <XS：ドキュメント>今年の日のカンマ区切りリスト。有効な値は1から366にまたは-366です-1 </ XS：ドキュメント>。</ XS：注釈> </ XS：属性> <XS：属性名= "BYWEEKNO" タイプ= "XS：文字列" 使用=」オプション "> <XS：注釈> <XS：ドキュメント>年の週を指定する序数のカンマ区切りリスト。有効な値は-1に1 -53〜53かです。</ XS：ドキュメント>。</ XS：注釈> </ XS：属性> <XS：属性名= "BYMONTH" タイプ= "XS：文字列" 使用=」オプション "> <XS：注釈> <XS：ドキュメント>年の月のカンマ区切りリスト。
Valid values are 1 to 12.</xs:documentation> </xs:annotation> </xs:attribute> <xs:attribute name="wkst" type="DayType" default="MO"/> <xs:attribute name="bysetpos" type="YearDayType"/> <xs:anyAttribute namespace="##any" processContents="lax"/> </xs:complexType> <xs:simpleType name="TZIDType"> <xs:restriction base="xs:string"/> </xs:simpleType> <xs:simpleType name="TZURLType"> <xs:restriction base="xs:anyURI"/> </xs:simpleType> <xs:complexType name="TimeSwitchType"> <xs:complexContent> <xs:extension base="SwitchType"> <xs:sequence> <xs:element name="time" type="TimeType" minOccurs="0" maxOccurs="unbounded"/> <xs:sequence minOccurs="0"> <xs:element name="not-present" type="NotPresentAction"/> <xs:element name="time" type="TimeType" minOccurs="0" maxOccurs="unbounded"/> </xs:sequence> <xs:element name="otherwise" type="OtherwiseAction" minOccurs="0"/> </xs:sequence> <xs:attribute name="tzid" type="TZIDType"/> <xs:attribute name="tzurl" type="TZURLType"/> </xs:extension> </xs:complexContent> </xs:complexType> <xs:element name="time-switch" type="TimeSwitchType" substitutionGroup="switch"/> <xs:simpleType name="PriorityValues"> <xs:restriction base="xs:NMTOKEN"> <xs:pattern value="[e|E][m|M][e|E][r|R][g|G][e|E][n|N][c|C][y|Y]"/> <xs:pattern value="[u|U][r|R][g|G][e|E][n|N][t|T]"/> <xs:pattern value="[n|N][o|O][r|R][m|M][a|A][l|L]"/> <xs:pattern value="[n|N][o|O][n|N]-[u|U][r|R][g|G][e|E][n|N][t|T]"/> </xs:restriction> </xs:simpleType> <xs:complexType name="PriorityType"> <xs:annotation> <xs:documentation>Exactly one of the three attributes must appear </xs:documentation>
有効な値は1〜12です。</ XS：ドキュメント>。</ XS：注釈> </ XS：属性> <XS：属性名= "のWkst" タイプ= "DayType" デフォルト= "MO" /> <XS：属性名前= "BYSETPOS" タイプ= "YearDayType" /> <XS：anyAttributeは名前空間= "##あらゆる" のprocessContents = "緩い" /> </ XS：complexTypeの> <XS：単純型名= "TZIDType"> <XS：制限基地= "XS：文字列" /> </ XS：単純> <XS：単純型名= "TZURLType"> <XS：制限ベース= "XS：anyURIの" /> </ XS：単純> <XS：complexTypeの名前= "TimeSwitchType"> <XS：complexContentを> <XS：増設ベース= "SWITCHTYPE"> <XS：配列> <XS：要素名= "時間" タイプ= "TimeType" のminOccurs = "0" のmaxOccurs = "無制限" /> <XS：配列のminOccurs = "0"> <XS：要素名= "-存在しない" タイプ= "NotPresentAction" /> <XS：要素名= "時間" タイプ= "TimeType" のminOccurs = "0" のmaxOccurs =」無制限 "/> </ XS：シーケンス> <XS：要素名=" それ以外 "タイプ= "OtherwiseAction" のminOccurs = "0"/> </ XS：シーケンス> <XS：属性名= "TZID" タイプ=" TZIDType "/> <XS：属性名=" tzurl」タイプ= "TZURLType" /> </ XS：拡張> </ XS：complexConten T> </ XS：complexTypeの> <XS：要素名= "タイムスイッチ" タイプ= "TimeSwitchType" のsubstitutionGroup = "スイッチ" /> <XS：simpleTypeの名前= "PriorityValues"> <XS：制限基地= "XS： NMTOKEN "> <XS：パターン値=" [E | E] [M | M] [E | E] [R | R] [G | G] [E | E] [N | N] [C | C] [Y | Y] "/> <XS：パターン値=" [U | U] [R | R] [G | G] [E | E] [N | N] [T | T] "/> <XS ：パターン値= "[N | N] [O | O] [R | R] [M | M] [| A] [L | L]" /> <XS：パターン値= "[N | N] [O | O] [N | N] - [U | U] [R | R] [G | G] [E | E] [N | N] [T | T] "/> </ XS：制限> </ XS：単純> <XS：complexTypeの名前= "PriorityType"> <XS：注釈> <XS：ドキュメント>正確に3つの属性のいずれかが表示されなければなりません。</ XS：ドキュメントを>
</xs:annotation> <xs:group ref="Node"/> <xs:attribute name="less" type="PriorityValues"/> <xs:attribute name="greater" type="PriorityValues"/> <xs:attribute name="equal" type="xs:string"> <xs:annotation> <xs:documentation>case-insensitive</xs:documentation> </xs:annotation> </xs:attribute> <xs:anyAttribute namespace="##any" processContents="lax"/> </xs:complexType> <xs:complexType name="PrioritySwitchType"> <xs:complexContent> <xs:extension base="SwitchType"> <xs:sequence> <xs:element name="priority" type="PriorityType" minOccurs="0" maxOccurs="unbounded"/> <xs:sequence minOccurs="0"> <xs:element name="not-present" type="NotPresentAction"/> <xs:element name="priority" type="PriorityType" minOccurs="0" maxOccurs="unbounded"/> </xs:sequence> <xs:element name="otherwise" type="OtherwiseAction" minOccurs="0"/> </xs:sequence> </xs:extension> </xs:complexContent> </xs:complexType> <xs:element name="priority-switch" type="PrioritySwitchType" substitutionGroup="switch"/> <xs:simpleType name="LocationPriorityType"> <xs:restriction base="xs:float"> <xs:minInclusive value="0.0"/> <xs:maxInclusive value="1.0"/> </xs:restriction> </xs:simpleType> <xs:complexType name="LocationType"> <xs:complexContent> <xs:extension base="ModifierType"> <xs:group ref="Node"/> <xs:attribute name="url" type="xs:anyURI" use="required"/> <xs:attribute name="priority" type="LocationPriorityType" use="optional" default="1.0"/> <xs:attribute name="clear" type="YesNoType" default="no"/> </xs:extension> </xs:complexContent> </xs:complexType> <xs:complexType name="LookupType">
</ XS：注釈> <XS：グループREF = "ノード" /> <XS：属性名= "少ない" タイプ= "PriorityValues" /> <XS：属性名= "大きい" タイプ= "PriorityValues" /> < XS：属性名= "等しい" タイプ= "XS：文字列"> <XS：注釈> <XS：ドキュメント>大文字と小文字を区別しない</ XS：ドキュメンテーション> </ XS：注釈> </ XS：属性> <XS： anyAttributeは名前空間= "##あらゆる" のprocessContents = "緩い" /> </ XS：complexTypeの> <XS：complexTypeの名前= "PrioritySwitchType"> <XS：complexContentを> <XS：増設ベース= "SWITCHTYPE"> <XS：シーケンス> <XS：要素名= "優先" タイプ= "PriorityType" のminOccurs = "0" のmaxOccurs = "無制限" /> <XS：配列のminOccurs = "0"> <XS：要素名= "-存在しない" タイプ= "NotPresentAction" /> <XS：要素名= "優先" タイプ= "PriorityType" のminOccurs = "0" のmaxOccurs = "無制限" /> </ XS：配列> <XS：要素名= "そうでなければ" タイプ= "OtherwiseAction "のminOccurs =" 0 "/> </ XS：配列> </ XS：拡張> </ XS：complexContentを> </ XS：complexTypeの> <XS：要素名=" 優先スイッチ」タイプ= "PrioritySwitchType" のsubstitutionGroup = "スイッチ" /> <XS：単純型名= "L ocationPriorityType "> <XS：制限ベース=" XS：フロート "> <XS：のminInclusive値=" 0.0 "/> <XS：maxInclusiveを値=" 1.0" /> </ XS：制限> </ XS：simpleTypeの> < XS：complexTypeの名前= "LocationType"> <XS：complexContentを> <XS：増設ベース= "ModifierType"> <XS：グループREF = "ノード" /> <XS：属性名= "URL" タイプ= "XS：anyURIの"使う=" 必須 "/> <XS：属性名=" 優先順位」タイプ= "LocationPriorityType" 使用= "オプションの" デフォルト= "1.0" /> <XS：属性名= "クリア" タイプ= "YesNoType" デフォルト= "ノー" /> </ XS：拡張> </ XS：complexContentを> </ XS：complexTypeの> <XS：complexTypeの名= "LookupType">
<xs:complexContent> <xs:extension base="ModifierType"> <xs:all> <xs:element name="success" minOccurs="0"> <xs:complexType> <xs:group ref="Node"/> </xs:complexType> </xs:element> <xs:element name="notfound" minOccurs="0"> <xs:complexType> <xs:group ref="Node"/> </xs:complexType> </xs:element> <xs:element name="failure" minOccurs="0"> <xs:complexType> <xs:group ref="Node"/> </xs:complexType> </xs:element> </xs:all> <xs:attribute name="source" type="xs:string" use="required"/> <xs:attribute name="timeout" type="xs:positiveInteger" default="30"/> <xs:attribute name="clear" type="YesNoType" default="no"/> </xs:extension> </xs:complexContent> </xs:complexType> <xs:complexType name="RemoveLocationType"> <xs:complexContent> <xs:extension base="ModifierType"> <xs:group ref="Node"/> <xs:attribute name="location" type="xs:string" use="optional"/> </xs:extension> </xs:complexContent> </xs:complexType> <xs:complexType name="LogAction"> <xs:complexContent> <xs:extension base="ActionType"> <xs:group ref="Node"/> <xs:attribute name="name" type="xs:string" use="optional"/> <xs:attribute name="comment" type="xs:string" use="optional"/> </xs:extension> </xs:complexContent> </xs:complexType> <xs:element name="log" type="LogAction" substitutionGroup="action"/>
<XS：complexContentを> <XS：拡張ベース= "ModifierType"> <XS：すべて> <XS：要素名= "成功" のminOccurs = "0"> <XS：complexTypeの> <XS：グループREF = "ノード" / > </ XS：complexTypeの> </ XS：要素> <XS：要素名= "NOTFOUND" のminOccurs = "0"> <XS：complexTypeの> <XS：グループREF = "ノード" /> </ XS：complexTypeの> </ XS：要素> <XS：要素名= "失敗" のminOccurs = "0"> <XS：complexTypeの> <XS：グループREF = "ノード" /> </ XS：complexTypeの> </ XS：要素> < / XS：すべて> <XS：属性名= "ソース" タイプ= "XS：文字列" 使用= "必須" /> <XS：属性名は= "タイムアウト" タイプ= "XS：POSITIVEINTEGER" デフォルト= "30" / > <XS：属性名= "クリア" タイプ= "YesNoType" デフォルト= "なし" /> </ XS：拡張> </ XS：complexContentを> </ XS：complexTypeの> <XS：complexTypeの名= "RemoveLocationType"> <XS：complexContentを> <XS：拡張ベースは= "ModifierType"> <XS：グループREF = "ノード" /> <XS：属性名= "位置" タイプ= "XS：文字列" 使用= "オプション" /> < / XS：拡張> </ XS：complexContentを> </ XS：complexTypeの> <XS：complexTypeの名前= "LogActionメソッド"> <XS：complexContentを> <XS：増設ベース= "ACTIONTYPE"> <XS：グループREF = "ノード" /> <XS：属性名= "名前" タイプ= "XS：文字列" 使用= "オプション" /> <XS：属性名= "コメント" タイプ= "XS：文字列" 使用= "オプション"/> </ XS：拡張> </ XS：complexContentを> </ XS：complexTypeの> <XS：要素名=" ログイン」タイプ= "LogActionメソッド" のsubstitutionGroup = "アクション" />
<xs:complexType name="IncomingType"> <xs:complexContent> <xs:extension base="TopLevelActionType"/> </xs:complexContent> </xs:complexType> <xs:element name="incoming" type="IncomingType" substitutionGroup="toplevelaction"/> <xs:complexType name="OutgoingType"> <xs:complexContent> <xs:extension base="TopLevelActionType"/> </xs:complexContent> </xs:complexType> <xs:element name="outgoing" type="OutgoingType" substitutionGroup="toplevelaction"/> <xs:complexType name="ProxyAction"> <xs:complexContent> <xs:extension base="ActionType"> <xs:all> <xs:element name="busy" minOccurs="0"> <xs:complexType> <xs:group ref="Node"/> </xs:complexType> </xs:element> <xs:element name="noanswer" minOccurs="0"> <xs:complexType> <xs:group ref="Node"/> </xs:complexType> </xs:element> <xs:element name="failure" minOccurs="0"> <xs:complexType> <xs:group ref="Node"/> </xs:complexType> </xs:element> <xs:element name="redirection" minOccurs="0"> <xs:complexType> <xs:group ref="Node"/> </xs:complexType> </xs:element> <xs:element name="default" minOccurs="0"> <xs:complexType> <xs:group ref="Node"/> </xs:complexType> </xs:element> </xs:all> <xs:attribute name="timeout" type="xs:positiveInteger" use="optional" default="20"/> <xs:attribute name="recurse" type="YesNoType" use="optional" default="yes"/>
<XS：complexTypeの名前= "IncomingType"> <XS：complexContentを> <XS：拡張ベース= "TopLevelActionType" /> </ XS：complexContentを> </ XS：complexTypeの> <XS：要素名= "受信" タイプ=」 IncomingType」のsubstitutionGroup = "toplevelaction" /> <XS：complexTypeの名= "OutgoingType"> <XS：complexContentを> <XS：増設ベース= "TopLevelActionType" /> </ XS：complexContentを> </ XS：complexTypeの> <XS：要素名= "発信" タイプ= "OutgoingType" のsubstitutionGroup = "toplevelaction" /> <XS：complexTypeの名= "また、ProxyAction"> <XS：complexContentを> <XS：増設ベース= "ACTIONTYPE"> <XS：すべて> <XS ：要素名= "忙しい" のminOccurs = "0"> <XS：complexTypeの> <XS：グループREF = "ノード" /> </ XS：complexTypeの> </ XS：要素> <XS：要素名= "noanswer" minOccurs = "0"> <XS：complexTypeの> <XS：グループREF = "ノード" /> </ XS：complexTypeの> </ XS：要素> <XS：要素名= "失敗" のminOccurs = "0"> < XS：complexTypeの> <XS：グループREF = "ノード" /> </ XS：complexTypeの> </ XS：要素> <XS：要素名= "リダイレクト" のminOccurs = "0"> <XS：complexTypeの> <XS：グループREF = "ノード" /> </ XS：complexTypeの> </ XS：要素> <XS：要素名= "デフォルト" のminOccurs = "0"> <XS：complexTypeの> <XS：グループREF = "ノード" /> </ XS：complexTypeの> </ XS：要素> </ XS：すべて> <XS：属性名= "タイムアウト" タイプ= "XS：POSITIVEINTEGER" 使用= "オプションの" デフォルト= "20" /> <XS：属性名= "再帰" タイプ= "YesNoType" 使用= "オプションの" デフォルト=」はい "/>
<xs:attribute name="ordering" type="OrderingType" use="optional" default="parallel"/> </xs:extension> </xs:complexContent> </xs:complexType> <xs:element name="proxy" type="ProxyAction" substitutionGroup="action"/> <xs:complexType name="RedirectAction"> <xs:complexContent> <xs:extension base="ActionType"> <xs:attribute name="permanent" type="YesNoType" default="no"/> </xs:extension> </xs:complexContent> </xs:complexType> <xs:element name="redirect" type="RedirectAction" substitutionGroup="action"/> <xs:complexType name="RejectAction"> <xs:complexContent> <xs:extension base="ActionType"> <xs:attribute name="status" type="StatusType" use="required"/> <xs:attribute name="reason" type="xs:string" use="optional"/> </xs:extension> </xs:complexContent> </xs:complexType> <xs:element name="reject" type="RejectAction" substitutionGroup="action"/> <xs:complexType name="MailAction"> <xs:complexContent> <xs:extension base="ActionType"> <xs:group ref="Node"/> <xs:attribute name="url" type="xs:anyURI" use="required"/> </xs:extension> </xs:complexContent> </xs:complexType> <xs:element name="mail" type="MailAction" substitutionGroup="action"/> <xs:complexType name="SubAction"> <xs:attribute name="ref" type="xs:string" use="required"/> </xs:complexType> <xs:complexType name="AncillaryType"/> <xs:complexType name="SubactionType"> <xs:group ref="Node"/> <xs:attribute name="id" use="required"/> </xs:complexType> <xs:complexType name="CPLType">
<XS：属性名= "発注" タイプ= "OrderingType" 使用= "オプションの" デフォルト= "パラレル" /> </ XS：拡張> </ XS：complexContentを> </ XS：complexTypeの> <XS：要素名= "プロキシ" タイプ= "また、ProxyAction" のsubstitutionGroup = "アクション" /> <XS：complexTypeの名前は= "RedirectAction"> <XS：complexContentを> <XS：増設ベース= "ACTIONTYPE"> <XS：属性名= "永久" タイプ= "YesNoType" デフォルト= "なし" /> </ XS：拡張> </ XS：complexContentを> </ XS：complexTypeの> <XS：要素名= "リダイレクト" タイプ= "RedirectAction" のsubstitutionGroup = "アクション" /> <XS：complexTypeの名前= "RejectAction"> <XS：complexContentを> <XS：拡張ベース= "ACTIONTYPE"> <XS：属性名= "ステータス" タイプ= "StatusType" 使用= "必須" /> <XS：属性名前= "理由" タイプ= "XS：文字列" 使用= "オプション" /> </ XS：拡張> </ XS：complexContentを> </ XS：complexTypeの> <XS：要素名= "拒否" タイプ= "RejectAction "のsubstitutionGroup =" アクション "/> <XS：complexTypeの名=" MailAction "> <XS：complexContentを> <XS：拡張ベース=" ACTIONTYPE "> <XS：グループREF =" ノード "/> <XS：属性名= "URL" タイプ= "XS：anyURIの"拡張子> </ XS：：complexContentを> </ XS：complexTypeの> <XS：要素名= "メール" タイプ= "MailAction" のsubstitutionGroup = "アクション" /> <XS：complexTypeの= "必要" /> </ XSを使用名前= "サブアクション"> <XS：属性名= "参照" タイプ= "XS：文字列"：complexTypeの> <XS：complexTypeの名= "AncillaryType" /> <XS：complexTypeの使用は= /> </ XS "必要"名前= "SubactionType"> <XS：グループREF = "ノード" /> <XS：属性名= "ID" 使用= "必須" /> </ XS：complexTypeの> <XS：complexTypeの名は= "CPLType">
<xs:sequence> <xs:element name="ancillary" type="AncillaryType" minOccurs="0" maxOccurs="1"/> <xs:element name="subaction" type="SubactionType" minOccurs="0" maxOccurs="unbounded"/> <xs:element ref="toplevelaction" minOccurs="0" maxOccurs="unbounded"> <xs:annotation> <xs:documentation>Any toplevel action MUST NOT appear more than once.</xs:documentation> </xs:annotation> </xs:element> </xs:sequence> </xs:complexType> <xs:element name="cpl" type="CPLType"/> </xs:schema> END
<XS：配列> <XS：要素名= "補助" タイプ= "AncillaryType" のminOccurs = "0" のmaxOccurs = "1" /> <XS：要素名= "サブアクション" タイプ= "SubactionType" のminOccurs = "0" maxOccurs = "無制限" /> <XS：要素REF = "toplevelaction" のminOccurs = "0" のmaxOccurs = "無制限"> <XS：注釈> <XS：ドキュメント>どれでもトップレベルのアクションが複数回現れてはならない</ XS。 ：ドキュメント> </ XS：注釈> </ XS：要素> </ XS：配列> </ XS：complexTypeの> <XS：要素名= "CPL" タイプ= "CPLType" /> </ XS：スキーマ> END
Normative References
引用規格
[1] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002.
[1]ローゼンバーグ、J.、Schulzrinneと、H.、カマリロ、G.、ジョンストン、A.、ピーターソン、J.、スパークス、R.、ハンドレー、M.、およびE.学生、 "SIP：セッション開始プロトコル" 、RFC 3261、2002年6月。
[2] Bray, T., Paoli, J., Sperberg-McQueen, C. M., Maler, E., and F. Yergeau, "Extensible Markup Language (XML) 1.0 (Third Edition)", W3C Recommendation REC-xml-20040204, World Wide Web Consortium (W3C), February 2004. Available at http://www.w3.org/XML/.
[2]ブレイ、T.、パオリ、J.、Sperberg-マックイーン、CM、MALER、E.、およびF. Yergeau、 "拡張マークアップ言語（XML）1.0（第3版）"、W3C勧告REC-XML-20040204 、World Wide Webコンソーシアム（W3C）、http://www.w3.org/XML/の利用可能な2004年2月。
[3] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[3]ブラドナーのは、S.は、BCP 14、RFC 2119、1997年3月の "RFCsにおける使用のためのレベルを示すために"。
[4] Hinden, R. and S. Deering, "Internet Protocol Version 6 (IPv6) Addressing Architecture", RFC 3513, April 2003.
[4] HindenとR.とS.デアリング、 "インターネットプロトコルバージョン6（IPv6）のアドレス指定アーキテクチャ"、RFC 3513、2003年4月。
[5] Davis, M. F. and M. Duerst, "Unicode Normalization Forms", Unicode Standard Annex #15, Unicode Consortium, April 2003. Revision 23; part of Unicode 4.0.0. Available at http://www.unicode.org/unicode/reports/tr15/.
[5]デイビス、M. F.及びM. Duerst、 "Unicode正規化フォーム"、Unicode標準の附属書＃15、ユニコードコンソーシアム、2003年4月改訂23。ユニコード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]デイビス、M. F.、 "ケースマッピング"、Unicode規格付属書＃21、ユニコードコンソーシアム、2001年3月改訂5。ユニコード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]ドーソン、F.と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]エッゲルト、P.、「タイムゾーンと夏時間データのソース」。 http://www.twinsun.com/tz/tz-link.htmで利用可能。
[10] Mealling, M. and R. Daniel, "URI Resolution Services Necessary for URN Resolution", RFC 2483, January 1999.
[10] Mealling、M.とR.ダニエル、 "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]ブレイ、T.、オランダ、D.、およびA.素人、 "XMLで名前空間"、W3C勧告REC-XML-名-19990114、World Wide Webコンソーシアム（W3C）、1999年1月には利用可能でhttp：/ /www.w3.org/TR/REC-xml-names/。
[12] Moats, R., "URN Syntax", RFC 2141, May 1997.
[12]堀、R.、 "URN構文"、RFC 2141、1997年5月。
[13] Moats, R., "A URN Namespace for IETF Documents", RFC 2648, August 1999.
[13]堀、R.、 "IETF文書のURN名前空間"、RFC 2648、1999年8月。
[14] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, January 2004.
[14] Mealling、M.、 "IETF XMLレジストリ"、BCP 81、RFC 3688、2004年1月。
[15] Murata, M., St.Laurent, S., and D. Kohn, "XML Media Types", RFC 3023, January 2001.
[15]村田、M.、St.Laurent、S.、およびD.コーン、 "XMLのメディアタイプ"、RFC 3023、2001年1月。
Informative References
参考文献
[16] International Telecommunication Union, "Packet-based multimedia communication systems", Recommendation H.323, Telecommunication Standardization Sector of ITU, Geneva, Switzerland, July 2003.
[16]国際電気通信連合、「パケットベースのマルチメディア通信システム」、勧告H.323、ITU、ジュネーブ、スイス、2003年7月の電気通信標準化部門。
[17] Lennox, J. and H. Schulzrinne, "Call Processing Language Framework and Requirements", RFC 2824, May 2000.
[17]レノックス、J.とH. Schulzrinneと、 "コール処理言語フレームワークと要件"、RFC 2824、2000年5月。
[18] Raggett, D., Le Hors, A., and I. Jacobs, "HTML 4.01 Specification", W3C Recommendation REC-html401-19991224, World Wide Web Consortium (W3C), December 1999. Available at http://www.w3.org/TR/html4/.
[18] Raggett、D.、ル・オードブル、A.、およびI.ジェイコブス、 "HTML 4.01仕様書"、W3C勧告REC-html401-19991224、World Wide Webコンソーシアム（W3C）は、httpで1999年12月利用可能：// www.w3.org/TR/html4/。
[19] ISO (International Organization for Standardization), "Information processing -- Text and office systems -- Standard Generalized Markup Language (SGML)", ISO Standard ISO 8879:1986(E), International Organization for Standardization, Geneva, Switzerland, October 1986.
[19] ISO（国際標準化機構）、 "情報処理 - テキストとオフィスシステム - 標準一般化マークアップ言語（SGML）"、ISO規格ISO 8879：1986（E）、標準化、ジュネーブ、スイス、国際機関1986年10月。
[20] ISO (International Organization for Standardization), "Data elements and interchange formats -- Information interchange -- Representation of dates and times", ISO Standard ISO 8601:2000(E), International Organization for Standardization, Geneva, Switzerland, December 2000.
[20] ISO（国際標準化機構）、「データ要素と交換フォーマット - 情報交換 - 日付と時刻の表現」、ISO規格ISO 8601：2000（E）、標準化、ジュネーブ、スイス、12月の国際組織2000。
[21] DeRose, S., Maler, E., Orchard, D., and B. Trafford, "XML Linking Language (XLink) Version 1.0", W3C Recommendation REC-xlink-20010627, World Wide Web Consortium (W3C), June 2001. Available at http://www.w3.org/TR/xlink/.
[21] DeRose、S.、MALER、E.、オーチャード、D.、およびB.トラフォード、 "XMLリンク言語（XLinkの）バージョン1.0"、W3C勧告REC-XLINK-20010627、World Wide Webコンソーシアム（W3C） 2001年6月http://www.w3.org/TR/xlink/利用可能。
[22] Showalter, T., "Sieve: A Mail Filtering Language", RFC 3028, January 2001.
[22]ショーウォルター監督、T.、 "ふるい：メールフィルタ言語"、RFC 3028、2001年1月。
[23] International Telecommunication Union, "Digital Subscriber Signalling System No. 1 (DSS 1) - ISDN user-network interface layer 3 specification for basic call control", Recommendation Q.931, International Telecommunication Union, Geneva, Switzerland, March 1993.
[23]国際電気通信連合、 - 、勧告Q.931、国際電気通信連合、ジュネーブ、スイス、1993年3月「デジタル加入者線信号システム第1号（DSS 1）基本呼制御のためのISDNユーザ・網インタフェースレイヤ3仕様」。
[24] Levin, O., "H.323 Uniform Resource Locator (URL) Scheme Registration", RFC 3508, April 2003.
[24]レヴィン、O.、 "H.323のURL（Uniform Resource Locator）スキームの登録"、RFC 3508、2003年4月。
Authors' Addresses
著者のアドレス
Jonathan Lennox Dept. of Computer Science Columbia University 1214 Amsterdam Avenue, MC 0401 New York, NY 10027 USA
コンピュータサイエンスコロンビア大学1214アムステルダムAvenue、MC 0401ニューヨークのジョナサン・レノックス部門、NY 10027 USA
EMail: lennox@cs.columbia.edu
メールアドレス：lennox@cs.columbia.edu
Xiaotao Wu Dept. of Computer Science Columbia University 1214 Amsterdam Avenue, MC 0401 New York, NY 10027 USA
コンピュータサイエンスコロンビア大学1214アムステルダムAvenue、MC 0401ニューヨークのXiaotao呉部長、NY 10027 USA
EMail: xiaotaow@cs.columbia.edu
メールアドレス：xiaotaow@cs.columbia.edu
Henning Schulzrinne Dept. of Computer Science Columbia University 1214 Amsterdam Avenue, MC 0401 New York, NY 10027 USA
コンピュータサイエンスコロンビア大学1214アムステルダムAvenue、MC 0401ニューヨークのヘニングSchulzrinneと部長、NY 10027 USA
EMail: schulzrinne@cs.columbia.edu
メールアドレス：schulzrinne@cs.columbia.edu
Full Copyright Statement
完全な著作権声明
Copyright (C) The Internet Society (2004).
著作権（C）インターネット協会（2004）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
この文書では、BCP 78に含まれる権利と許可と制限の適用を受けており、その中の記載を除いて、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットソサエティおよびインターネット・エンジニアリング・タスク・フォース放棄すべての保証、明示または、（もしあれば）後援ISに設けられています。黙示、情報の利用は、特定の目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証含むがこれらに限定されません。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the IETF's procedures with respect to rights in IETF Documents can be found in BCP 78 and BCP 79.
IETFは、本書またはそのような権限下で、ライセンスがたりないかもしれない程度に記載された技術の実装や使用に関係すると主張される可能性があります任意の知的財産権やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能です。またそれは、それがどのような権利を確認する独自の取り組みを行ったことを示すものでもありません。 IETF文書の権利に関するIETFの手続きの情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができます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 Editor機能のための基金は現在、インターネット協会によって提供されます。