RFC3880 日本語訳
3880 Call Processing Language (CPL): A Language for User Control ofInternet Telephony Services. J. Lennox, X. Wu, H. Schulzrinne. October 2004. (Format: TXT=154991 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group J. Lennox
Request for Comments: 3880 X. Wu
Category: Standards Track H. Schulzrinne
Columbia University
October 2004
Network Working Group J. Lennox Request for Comments: 3880 X. Wu Category: Standards Track H. Schulzrinne Columbia University October 2004
Call Processing Language (CPL):
A Language for User Control of Internet Telephony Services
Call Processing Language (CPL): A Language for User Control of Internet Telephony Services
Status of this Memo
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.
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.
Copyright Notice
Copyright Notice
Copyright (C) The Internet Society (2004).
Copyright (C) The Internet Society (2004).
Abstract
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.
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.
Lennox, et al. Standards Track [Page 1] RFC 3880 CPL October 2004
Lennox, et al. Standards Track [Page 1] RFC 3880 CPL October 2004
Table of Contents
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Conventions of This Document. . . . . . . . . . . . . . 4
2. Structure of CPL Scripts . . . . . . . . . . . . . . . . . . . 4
2.1. High-level Structure. . . . . . . . . . . . . . . . . . 4
2.2. Abstract Structure of a Call Processing Action. . . . . 5
2.3. Location Model. . . . . . . . . . . . . . . . . . . . . 6
2.4. XML Structure . . . . . . . . . . . . . . . . . . . . . 6
3. Script Structure: Overview . . . . . . . . . . . . . . . . . . 7
4. Switches . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
4.1. Address Switches. . . . . . . . . . . . . . . . . . . . 9
4.1.1. Usage of "address-switch" with SIP. . . . . . . 11
4.2. String Switches . . . . . . . . . . . . . . . . . . . . 12
4.2.1. Usage of "string-switch" with SIP . . . . . . . 13
4.3. Language Switches . . . . . . . . . . . . . . . . . . . 14
4.3.1. Usage of "language-switch" with SIP . . . . . . 14
4.4. Time Switches . . . . . . . . . . . . . . . . . . . . . 15
4.4.1. iCalendar differences and implementation
issues. . . . . . . . . . . . . . . . . . . . . 20
4.5. Priority Switches . . . . . . . . . . . . . . . . . . . 21
4.5.1. Usage of "priority-switch" with SIP . . . . . . 22
5. Location Modifiers . . . . . . . . . . . . . . . . . . . . . . 22
5.1. Explicit Location . . . . . . . . . . . . . . . . . . . 23
5.1.1. Usage of "location" with SIP. . . . . . . . . . 23
5.2. Location Lookup . . . . . . . . . . . . . . . . . . . . 24
5.2.1. Usage of "lookup" with SIP. . . . . . . . . . . 25
5.3. Location Removal. . . . . . . . . . . . . . . . . . . . 25
5.3.1. Usage of "remove-location" with SIP . . . . . . 26
6. Signalling Operations. . . . . . . . . . . . . . . . . . . . . 26
6.1. Proxy . . . . . . . . . . . . . . . . . . . . . . . . . 26
6.1.1. Usage of "proxy" with SIP . . . . . . . . . . . 29
6.2. Redirect. . . . . . . . . . . . . . . . . . . . . . . . 29
6.2.1. Usage of "redirect" with SIP. . . . . . . . . . 30
6.3. Reject. . . . . . . . . . . . . . . . . . . . . . . . . 30
6.3.1. Usage of "reject" with SIP. . . . . . . . . . . 30
7. Non-signalling Operations. . . . . . . . . . . . . . . . . . . 31
7.1. Mail. . . . . . . . . . . . . . . . . . . . . . . . . . 31
7.1.1. Suggested Content of Mailed Information . . . . 32
7.2. Log . . . . . . . . . . . . . . . . . . . . . . . . . . 32
8. Subactions . . . . . . . . . . . . . . . . . . . . . . . . . . 33
9. Ancillary Information. . . . . . . . . . . . . . . . . . . . . 34
10. Default Behavior . . . . . . . . . . . . . . . . . . . . . . . 35
11. CPL Extensions . . . . . . . . . . . . . . . . . . . . . . . . 35
12. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
12.1. Example: Call Redirect Unconditional. . . . . . . . . . 37
12.2. Example: Call Forward Busy/No Answer. . . . . . . . . . 38
12.3. Example: Call Forward: Redirect and Default . . . . . . 39
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Conventions of This Document. . . . . . . . . . . . . . 4 2. Structure of CPL Scripts . . . . . . . . . . . . . . . . . . . 4 2.1. High-level Structure. . . . . . . . . . . . . . . . . . 4 2.2. Abstract Structure of a Call Processing Action. . . . . 5 2.3. Location Model. . . . . . . . . . . . . . . . . . . . . 6 2.4. XML Structure . . . . . . . . . . . . . . . . . . . . . 6 3. Script Structure: Overview . . . . . . . . . . . . . . . . . . 7 4. Switches . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 4.1. Address Switches. . . . . . . . . . . . . . . . . . . . 9 4.1.1. Usage of "address-switch" with SIP. . . . . . . 11 4.2. String Switches . . . . . . . . . . . . . . . . . . . . 12 4.2.1. Usage of "string-switch" with SIP . . . . . . . 13 4.3. Language Switches . . . . . . . . . . . . . . . . . . . 14 4.3.1. Usage of "language-switch" with SIP . . . . . . 14 4.4. Time Switches . . . . . . . . . . . . . . . . . . . . . 15 4.4.1. iCalendar differences and implementation issues. . . . . . . . . . . . . . . . . . . . . 20 4.5. Priority Switches . . . . . . . . . . . . . . . . . . . 21 4.5.1. Usage of "priority-switch" with SIP . . . . . . 22 5. Location Modifiers . . . . . . . . . . . . . . . . . . . . . . 22 5.1. Explicit Location . . . . . . . . . . . . . . . . . . . 23 5.1.1. Usage of "location" with SIP. . . . . . . . . . 23 5.2. Location Lookup . . . . . . . . . . . . . . . . . . . . 24 5.2.1. Usage of "lookup" with SIP. . . . . . . . . . . 25 5.3. Location Removal. . . . . . . . . . . . . . . . . . . . 25 5.3.1. Usage of "remove-location" with SIP . . . . . . 26 6. Signalling Operations. . . . . . . . . . . . . . . . . . . . . 26 6.1. Proxy . . . . . . . . . . . . . . . . . . . . . . . . . 26 6.1.1. Usage of "proxy" with SIP . . . . . . . . . . . 29 6.2. Redirect. . . . . . . . . . . . . . . . . . . . . . . . 29 6.2.1. Usage of "redirect" with SIP. . . . . . . . . . 30 6.3. Reject. . . . . . . . . . . . . . . . . . . . . . . . . 30 6.3.1. Usage of "reject" with SIP. . . . . . . . . . . 30 7. Non-signalling Operations. . . . . . . . . . . . . . . . . . . 31 7.1. Mail. . . . . . . . . . . . . . . . . . . . . . . . . . 31 7.1.1. Suggested Content of Mailed Information . . . . 32 7.2. Log . . . . . . . . . . . . . . . . . . . . . . . . . . 32 8. Subactions . . . . . . . . . . . . . . . . . . . . . . . . . . 33 9. Ancillary Information. . . . . . . . . . . . . . . . . . . . . 34 10. Default Behavior . . . . . . . . . . . . . . . . . . . . . . . 35 11. CPL Extensions . . . . . . . . . . . . . . . . . . . . . . . . 35 12. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 37 12.1. Example: Call Redirect Unconditional. . . . . . . . . . 37 12.2. Example: Call Forward Busy/No Answer. . . . . . . . . . 38 12.3. Example: Call Forward: Redirect and Default . . . . . . 39
Lennox, et al. Standards Track [Page 2] RFC 3880 CPL October 2004
Lennox, et al. Standards Track [Page 2] RFC 3880 CPL October 2004
12.4. Example: Call Screening . . . . . . . . . . . . . . . . 40
12.5. Example: Priority and Language Routing. . . . . . . . . 41
12.6. Example: Outgoing Call Screening. . . . . . . . . . . . 42
12.7. Example: Time-of-day Routing. . . . . . . . . . . . . . 43
12.8. Example: Location Filtering . . . . . . . . . . . . . . 44
12.9. Example: Non-signalling Operations. . . . . . . . . . . 45
12.10. Example: Hypothetical Extensions. . . . . . . . . . . . 46
12.11. Example: A Complex Example. . . . . . . . . . . . . . . 48
13. Security Considerations. . . . . . . . . . . . . . . . . . . . 49
14. IANA Considerations. . . . . . . . . . . . . . . . . . . . . . 49
14.1. URN Sub-Namespace Registration for
urn:ietf:params:xml:ns:cpl. . . . . . . . . . . . . . . 49
14.2. Schema registration . . . . . . . . . . . . . . . . . . 50
14.3. MIME Registration . . . . . . . . . . . . . . . . . . . 50
15. Acknowledgments. . . . . . . . . . . . . . . . . . . . . . . . 51
A. An Algorithm for Resolving Time Switches . . . . . . . . . . . 52
B. Suggested Usage of CPL with H.323. . . . . . . . . . . . . . . 53
B.1. Usage of "address-switch" with H.323. . . . . . . . . . 53
B.2. Usage of "string-switch" with H.323 . . . . . . . . . . 55
B.3. Usage of "language-switch" with H.323 . . . . . . . . . 55
B.4. Usage of "priority-switch" with H.323 . . . . . . . . . 55
B.5. Usage of "location" with H.323. . . . . . . . . . . . . 56
B.6. Usage of "lookup" with H.323. . . . . . . . . . . . . . 56
B.7. Usage of "remove-location" with H.323 . . . . . . . . . 56
C. The XML Schema for CPL . . . . . . . . . . . . . . . . . . . . 56
Normative References . . . . . . . . . . . . . . . . . . . . . . . 70
Informative References . . . . . . . . . . . . . . . . . . . . . . 71
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 73
Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 74
12.4. Example: Call Screening . . . . . . . . . . . . . . . . 40 12.5. Example: Priority and Language Routing. . . . . . . . . 41 12.6. Example: Outgoing Call Screening. . . . . . . . . . . . 42 12.7. Example: Time-of-day Routing. . . . . . . . . . . . . . 43 12.8. Example: Location Filtering . . . . . . . . . . . . . . 44 12.9. Example: Non-signalling Operations. . . . . . . . . . . 45 12.10. Example: Hypothetical Extensions. . . . . . . . . . . . 46 12.11. Example: A Complex Example. . . . . . . . . . . . . . . 48 13. Security Considerations. . . . . . . . . . . . . . . . . . . . 49 14. IANA Considerations. . . . . . . . . . . . . . . . . . . . . . 49 14.1. URN Sub-Namespace Registration for urn:ietf:params:xml:ns:cpl. . . . . . . . . . . . . . . 49 14.2. Schema registration . . . . . . . . . . . . . . . . . . 50 14.3. MIME Registration . . . . . . . . . . . . . . . . . . . 50 15. Acknowledgments. . . . . . . . . . . . . . . . . . . . . . . . 51 A. An Algorithm for Resolving Time Switches . . . . . . . . . . . 52 B. Suggested Usage of CPL with H.323. . . . . . . . . . . . . . . 53 B.1. Usage of "address-switch" with H.323. . . . . . . . . . 53 B.2. Usage of "string-switch" with H.323 . . . . . . . . . . 55 B.3. Usage of "language-switch" with H.323 . . . . . . . . . 55 B.4. Usage of "priority-switch" with H.323 . . . . . . . . . 55 B.5. Usage of "location" with H.323. . . . . . . . . . . . . 56 B.6. Usage of "lookup" with H.323. . . . . . . . . . . . . . 56 B.7. Usage of "remove-location" with H.323 . . . . . . . . . 56 C. The XML Schema for CPL . . . . . . . . . . . . . . . . . . . . 56 Normative References . . . . . . . . . . . . . . . . . . . . . . . 70 Informative References . . . . . . . . . . . . . . . . . . . . . . 71 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 73 Full Copyright Statement . . . . . . . . . . . . . . . . . . . . . 74
1. Introduction
1. Introduction
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].
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 is powerful enough to describe a large number of services and features, but it is limited in power so that it can run safely in Internet telephony servers. The intention is to make it impossible for users to do anything more complex (and dangerous) than describe Internet telephony services. The language is not Turing-complete, and provides no way to write loops or recursion.
CPL is powerful enough to describe a large number of services and features, but it is limited in power so that it can run safely in Internet telephony servers. The intention is to make it impossible for users to do anything more complex (and dangerous) than describe Internet telephony services. The language is not Turing-complete, and provides no way to write loops or recursion.
CPL is also designed to be easily created and edited by graphical tools. It is based on the Extensible Markup Language (XML) [2], so parsing it is easy and many parsers for it are publicly available.
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.
Lennox, et al. Standards Track [Page 3] RFC 3880 CPL October 2004
Lennox, et al. Standards Track [Page 3] RFC 3880 CPL October 2004
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.
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.
Implementations of CPL are expected to take place both in Internet telephony servers and in advanced clients; both can usefully process and direct users' calls. This document primarily addresses the usage in servers. A mechanism will be needed to transport scripts between clients and servers; this document does not describe such a mechanism, but related documents will.
The framework and requirements for the CPL architecture are described in RFC 2824, "Call Processing Language Framework and Requirements" [17].
The framework and requirements for the CPL architecture are described in RFC 2824, "Call Processing Language Framework and Requirements" [17].
1.1. Conventions of This Document
1.1. Conventions of This Document
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.
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.
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.
Some paragraphs are indented, like this; they give motivations of design choices, advice to implementors, or thoughts on future development of or extensions to CPL. They are not essential to the specification of the language, and are non-normative.
2. Structure of CPL Scripts
2. Structure of CPL Scripts
2.1. High-level Structure
2.1. High-level Structure
A CPL script consists of two types of information: ancillary information about the script, and call processing actions.
A CPL script consists of two types of information: ancillary information about the script, and call processing actions.
A call processing action is a structured tree that describes the operations and decisions a telephony signalling server performs on a call set-up event. There are two types of call processing actions: top-level actions and subactions. Top-level actions are actions that are triggered by signalling events that arrive at the server. Two top-level actions are defined: "incoming", the action performed when a call arrives whose destination is the owner of the script, and "outgoing", the action performed when a call arrives whose originator is the owner of the script.
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.
Lennox, et al. Standards Track [Page 4] RFC 3880 CPL October 2004
Lennox, et al. Standards Track [Page 4] RFC 3880 CPL October 2004
Subactions are actions which can be called from other actions. CPL forbids subactions from being called recursively: see Section 8.
Subactions are actions which can be called from other actions. CPL forbids subactions from being called recursively: see Section 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.
Ancillary information is information which is necessary for a server to correctly process a script, but which does not directly describe any operations or decisions. Currently, no ancillary information is defined, but the section is reserved for use by extensions.
2.2. Abstract Structure of a Call Processing Action
2.2. Abstract Structure of a Call Processing Action
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.
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.
For a graphical representation of a CPL action, see Figure 1. Nodes and outputs can be thought of informally as boxes and arrows; CPL is designed so that actions can be conveniently edited graphically using this representation. Nodes are arranged in a tree, starting at a single root node; outputs of nodes are connected to additional nodes. When an action is run, the action or decision described by the action's top-level node is performed; based on the result of that node, the server follows one of the node's outputs, and the subsequent node it points to is performed; this process continues until a node with no specified outputs is reached. Because the graph is acyclic, this will occur after a bounded and predictable number of nodes are visited.
If an output to a node does not point to another node, it indicates that the CPL server should perform a node- or protocol-specific action. Some nodes have specific default behavior associated with them; for others, the default behavior is implicit in the underlying signalling protocol, or can be configured by the administrator of the server. For further details on this, see Section 10.
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.
Lennox, et al. Standards Track [Page 5] RFC 3880 CPL October 2004
Lennox, et al. Standards Track [Page 5] RFC 3880 CPL October 2004
_________________ ___________________ ________ busy
| Address-switch | | location | | proxy |--------\
Call-->| field: origin | ->| url: sip:jones@ |->|timeout:| timeout|
| subfield: host | / | example.com | | 10s |--------|
|-----------------|/ |___________________| | | failure|
| subdomain-of: | |________|--------|
| example.com | |
|-----------------| ___________________________________________/
| otherwise | /........................................
| |\|. Voicemail .
|_________________| \. ____________________ .
->| location | __________ .
. | url: sip:jones@ | | redirect | .
. | voicemail. |->| | .
. | example.com | |__________| .
. |____________________| .
........................................
_________________ ___________________ ________ busy | Address-switch | | location | | proxy |--------\ Call-->| field: origin | ->| url: sip:jones@ |->|timeout:| timeout| | subfield: host | / | example.com | | 10s |--------| |-----------------|/ |___________________| | | failure| | subdomain-of: | |________|--------| | example.com | | |-----------------| ___________________________________________/ | otherwise | /........................................ | |\|. Voicemail . |_________________| \. ____________________ . ->| location | __________ . . | url: sip:jones@ | | redirect | . . | voicemail. |->| | . . | example.com | |__________| . . |____________________| . ........................................
Figure 1: Sample CPL Action: Graphical Version
Figure 1: Sample CPL Action: Graphical Version
2.3. Location Model
2.3. Location Model
For flexibility, one piece of information necessary for CPL is not given as node parameters: the set of locations to which a call is to be directed. Instead, this set of locations is stored as an implicit global variable throughout the execution of a processing action (and its subactions). This allows locations to be retrieved from external sources, filtered, and so forth, without requiring general language support for such operations (which could harm the simplicity and tractability of understanding the language). The specific operations which add, retrieve, or filter location sets are given in Section 5.
For flexibility, one piece of information necessary for CPL is not given as node parameters: the set of locations to which a call is to be directed. Instead, this set of locations is stored as an implicit global variable throughout the execution of a processing action (and its subactions). This allows locations to be retrieved from external sources, filtered, and so forth, without requiring general language support for such operations (which could harm the simplicity and tractability of understanding the language). The specific operations which add, retrieve, or filter location sets are given in Section 5.
For the incoming top-level call processing action, the location set is initialized to the empty set. For the outgoing action, it is initialized to the destination address of the call.
For the incoming top-level call processing action, the location set is initialized to the empty set. For the outgoing action, it is initialized to the destination address of the call.
2.4. XML Structure
2.4. XML Structure
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].
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].
Lennox, et al. Standards Track [Page 6] RFC 3880 CPL October 2004
Lennox, et al. Standards Track [Page 6] RFC 3880 CPL October 2004
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).
See Figure 2 for the XML document corresponding to the graphical representation of the CPL script in Figure 1. Both nodes and outputs in CPL are represented by XML tags; parameters are represented by XML tag attributes. Typically, node tags contain output tags, and vice- versa (with a few exceptions: see Sections 5.1, 5.3, 7.1, and 7.2).
The connection between the output of a node and another node is represented by enclosing the tag representing the pointed-to node inside the tag for the outer node's output. Convergence (several outputs pointing to a single node) is represented by subactions, discussed further in Section 8.
The connection between the output of a node and another node is represented by enclosing the tag representing the pointed-to node inside the tag for the outer node's output. Convergence (several outputs pointing to a single node) is represented by subactions, discussed further in Section 8.
The higher-level structure of a CPL script is represented by tags corresponding to each piece of ancillary information, subactions, and top-level actions, in order. This higher-level information is all enclosed in a special tag "cpl", the outermost tag of the XML document.
The higher-level structure of a CPL script is represented by tags corresponding to each piece of ancillary information, subactions, and top-level actions, in order. This higher-level information is all enclosed in a special tag "cpl", the outermost tag of the XML document.
A complete XML Schema for CPL is provided in Appendix C. The remainder of the main sections of this document describe the semantics of CPL, while giving its syntax informally. For the formal syntax, please see the appendix.
A complete XML Schema for CPL is provided in Appendix C. The remainder of the main sections of this document describe the semantics of CPL, while giving its syntax informally. For the formal syntax, please see the appendix.
3. Script Structure: Overview
3. Script Structure: Overview
As mentioned, a CPL script consists of ancillary information, subactions, and top-level actions. The full syntax of the "cpl" node is given in Figure 3.
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.
<?xml version="1.0" encoding="UTF-8"?>
<cpl xmlns="urn:ietf:params:xml:ns:cpl"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="urn:ietf:params:xml:ns:cpl cpl.xsd ">
<subaction id="voicemail">
<location url="sip:jones@voicemail.example.com">
<redirect />
</location>
</subaction>
<incoming>
<address-switch field="origin" subfield="host">
<address subdomain-of="example.com">
<location url="sip:jones@example.com">
<proxy timeout="10">
<busy> <sub ref="voicemail" /> </busy>
<noanswer> <sub ref="voicemail" /> </noanswer>
<failure> <sub ref="voicemail" /> </failure>
</proxy>
</location>
<?xml version="1.0" encoding="UTF-8"?> <cpl xmlns="urn:ietf:params:xml:ns:cpl" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="urn:ietf:params:xml:ns:cpl cpl.xsd "> <subaction id="voicemail"> <location url="sip:jones@voicemail.example.com"> <redirect /> </location> </subaction> <incoming> <address-switch field="origin" subfield="host"> <address subdomain-of="example.com"> <location url="sip:jones@example.com"> <proxy timeout="10"> <busy> <sub ref="voicemail" /> </busy> <noanswer> <sub ref="voicemail" /> </noanswer> <failure> <sub ref="voicemail" /> </failure> </proxy> </location>
Lennox, et al. Standards Track [Page 7] RFC 3880 CPL October 2004
Lennox, et al. Standards Track [Page 7] RFC 3880 CPL October 2004
</address>
<otherwise>
<sub ref="voicemail" />
</otherwise>
</address-switch>
</incoming>
</cpl>
</address> <otherwise> <sub ref="voicemail" /> </otherwise> </address-switch> </incoming> </cpl>
Figure 2: Sample CPL Script: XML Version
Figure 2: Sample CPL Script: XML Version
Tag: "cpl"
Parameters: None
Sub-tags: "ancillary" See Section 9
"subaction" See Section 8
"outgoing" Top-level actions to take on this user's
outgoing calls
"incoming" Top-level actions to take on this user's
incoming calls
Tag: "cpl" Parameters: None Sub-tags: "ancillary" See Section 9 "subaction" See Section 8 "outgoing" Top-level actions to take on this user's outgoing calls "incoming" Top-level actions to take on this user's incoming calls
Figure 3: Syntax of the top-level "cpl" tag
Figure 3: Syntax of the top-level "cpl" tag
Call processing actions, both top-level actions and subactions, consist of a tree of nodes and outputs. Nodes and outputs are both described by XML tags. There are four categories of CPL nodes: switches, which represent choices a CPL script can make, location modifiers, which add or remove locations from the location set, signalling operations, which cause signalling events in the underlying protocol, and non-signalling operations, which trigger behavior which does not effect the underlying protocol.
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.
4. Switches
4. Switches
Switches represent choices a CPL script can make, based on either attributes of the original call request or items independent of the call.
Switches represent choices a CPL script can make, based on either attributes of the original call request or items independent of the call.
All switches are arranged as a list of conditions that can match a variable. Each condition corresponds to a node output; the output points to the next node that should be executed if the condition is true. The conditions are tried in the order they are presented in the script; the output corresponding to the first node to match is taken.
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".)
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".)
Lennox, et al. Standards Track [Page 8] RFC 3880 CPL October 2004
Lennox, et al. Standards Track [Page 8] RFC 3880 CPL October 2004
The output "otherwise", which MUST be the last output specified if it is present, matches if no other condition matched.
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.
If no condition matches and no "otherwise" output was present in the script, the default script behavior is taken. See Section 10 for more information on this.
Switches MAY contain no outputs. They MAY only contain an "otherwise" output.
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.
Such switches are not particularly useful, but might be created by tools which automatically generate CPL scripts.
4.1. Address Switches
4.1. Address Switches
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.
Address switches allow a CPL script to make decisions based on one of the addresses present in the original call request. They are summarized in Figure 4.
Node: "address-switch"
Outputs: "address" Specific addresses to match
Parameters: "field" "origin", "destination",
or "original-destination"
"subfield" "address-type", "user", "host",
"port", "tel", or "display"
(also: "password" and "alias-type")
Node: "address-switch" Outputs: "address" Specific addresses to match Parameters: "field" "origin", "destination", or "original-destination" "subfield" "address-type", "user", "host", "port", "tel", or "display" (also: "password" and "alias-type")
Output: "address"
Parameters: "is" Exact match
"contains" Substring match (for "display" only)
"subdomain-of" Sub-domain match (for "host", "tel")
Output: "address" Parameters: "is" Exact match "contains" Substring match (for "display" only) "subdomain-of" Sub-domain match (for "host", "tel")
Figure 4: Syntax of the "address-switch" node
Figure 4: Syntax of the "address-switch" node
Address switches have two node parameters: "field" and "subfield". The mandatory "field" parameter allows the script to specify which address is to be considered for the switch: either the call's origin address (field "origin"), its current destination address (field "destination"), or its original destination (field "original- destination"), the destination the call had before any earlier forwarding was invoked. Servers MAY define additional field values.
Address switches have two node parameters: "field" and "subfield". The mandatory "field" parameter allows the script to specify which address is to be considered for the switch: either the call's origin address (field "origin"), its current destination address (field "destination"), or its original destination (field "original- destination"), the destination the call had before any earlier forwarding was invoked. Servers MAY define additional field values.
The optional "subfield" specifies which part of the address is to be considered. The possible subfield values are: "address-type", "user", "host", "port", "tel", and "display". Additional subfield values MAY be defined for protocol-specific values. (The subfield "password" is defined for SIP in Section 4.1.1; the subfield "alias- type" is defined for H.323 in Appendix B.1.) If no subfield is
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
Lennox, et al. Standards Track [Page 9] RFC 3880 CPL October 2004
Lennox, et al. Standards Track [Page 9] RFC 3880 CPL October 2004
specified, the "entire" address is matched; the precise meaning of this is defined for each underlying signalling protocol. Servers MAY define additional subfield values.
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:
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.
address-type: This indicates the type of the underlying address, i.e., the URI scheme, if the address can be represented by a URI. The types specifically discussed by this document are "sip", "tel", and "h323". The address type is not case- sensitive. It has a value for all defined address types.
user: This subfield of the address indicates, for e-mail style
addresses, the user part of the address. For a telephone
number style address, it includes the subscriber number.
This subfield is case-sensitive; it may be absent.
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.
以下を接待してください。 アドレスのこの部分体はアドレスに対応するインターネット・ホスト名かIPアドレスを示します、ホスト名、IPv4、またはIPv6の[4]の原文の表現形式で。 ホスト名はストリングとして比較されます。 IPアドレスは数の上で比較されます。 (IPv6の存在か位置: : 省略されたゼロ・ビットブロックは合っている目的のために特に、重要ではありません。) ホスト名はIPアドレスと決して等しくはありません--DNS解決は全く実行されません。 IPv4アドレスはIPv6アドレスがv6のv4埋め込みであっても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ポートナンバーを数の上で示します。 それは、10進数字を含むだけでよいので、大文字と小文字を区別していません。 先行ゼロは無視されます。
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'を含むかもしれません)、欠けているかもしれません。 それが取り組んでいる使用であるかもしれない、「サブドメイン、-、」 オペレータを合わせてください。 電話番号の句読と分離符キャラクタは捨てられます。
Lennox, et al. Standards Track [Page 10] RFC 3880 CPL October 2004
レノックス、他 規格はCPL2004年10月にRFC3880を追跡します[10ページ]。
display: This subfield indicates a "display name" or user-visible
name corresponding to an address. It is a Unicode string,
and is matched using the case-insensitive algorithm
described in Section 4.2. The "contains" operator may be
applied to it. It may be absent.
表示: この部分体はアドレスに対応する「表示名」か目に見えるユーザ名を示します。 それは、ユニコードストリングであり、セクション4.2で説明された大文字と小文字を区別しないアルゴリズムを使用することで取り組んでいます。 「含有」オペレータはそれに適用されるかもしれません。 それは欠けているかもしれません。
For any completely unknown subfield, the server MAY reject the script at the time it is submitted with an indication of the problem; if a script with an unknown subfield is executed, the server MUST consider the "not-present" output to be the valid one.
どんな完全に未知の部分体のためにも、問題のしるしでそれを提出するとき、サーバはスクリプトを拒絶するかもしれません。 未知の部分体があるスクリプトが作成されるなら、サーバは、「プレゼントでない」出力が有効なものであると考えなければなりません。
The "address" output tag may take exactly one of three possible parameters, indicating the kind of matching allowed.
マッチングの種類が許容したのを示して、「アドレス」出力タグはちょうど3つの可能なパラメタの1つを取るかもしれません。
is: An output with this match operator is followed if the
subfield being matched in the "address-switch" exactly
matches the argument of the operator. It may be used for
any subfield, or for the entire address if no subfield was
specified.
あります: 「アドレススイッチ」で合わせられている部分体がまさにオペレータの議論に合っているなら、このマッチオペレータによる出力は続かれています。 それがどんな部分体にも使用されたかもしれませんか、または全体として、アドレスは部分体でないなら指定されました。
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.
含んでいます: このマッチオペレータは単に部分体「表示」に申し込みます。 合わせられている表示名がサブストリングとしてマッチの議論を含んでいるなら、出力は合っています。
4.1.1. Usage of "address-switch" with SIP
4.1.1. 一口がある「アドレススイッチ」の用法
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」に対応している、「元の目的地」は“To"ヘッダーに文通されます。
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の構文のために、「目的地」アドレス・フィールドには、「表示」部分体が決してないでしょう。
Lennox, et al. Standards Track [Page 11] RFC 3880 CPL October 2004
レノックス、他 規格はCPL2004年10月にRFC3880を追跡します[11ページ]。
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構文の「ユーザ」、「ホスト」、および「ポート」原理に対応しています。 (RFC3261[1]の定義に続いて、ポートを指定しないSIP URIが明白なポート5060と同じでないことに注意してください; 前者は欠けているポート部分体によって示されます。) "tel"部分体はURIの「ユーザ」部分になるように定義されます、視覚分離符を剥取っていて、「ユーザ=電話」パラメタをURIに与えるか、またはユーザ部分が電話番号であると認めるために別の方法でサーバを構成するなら。 「パスワード」という追加部分体は、SIP URIの「パスワード」要素に相当するように定義されて、ケース敏感です。 しかしながら、総合証券理由でこの分野の使用はNOT RECOMMENDEDです。
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.
h323URLにおいて、部分体はAppendix Bで説明された計画通りに設定されるかもしれません。
For other URI schemes, only the "address-type" subfield is defined by this specification; servers MAY set other pre-defined subfields, or MAY support additional subfields.
他の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は逐語的に使用されます。
4.2. String Switches
4.2. ストリングスイッチ
String switches allow a CPL script to make decisions based on free- form strings present in a call request. They are summarized in Figure 5.
ストリングスイッチで、CPLスクリプトで結合していないフォームストリングに基づく決定は発呼要求に存在するようになる場合があります。 それらは図5にまとめられます。
Node: "string-switch"
Outputs: "string" Specific string to match
Parameters: "field" "subject", "organization",
"user-agent", or "display"
ノード: 「ストリングスイッチ」出力: 「ストリング」SpecificはマッチParametersに以下を結びます。 「分野」「対象」、「組織」、「ユーザエージェント」、または「表示」
Output: "string"
Parameters: "is" Exact match
"contains" Substring match
出力: 「ストリング」パラメタ: Exactが合っている「存在」はSubstringマッチを「含んでいます」。
Figure 5: Syntax of the "string-switch" node
図5: 「ストリングスイッチ」ノードの構文
Lennox, et al. Standards Track [Page 12] RFC 3880 CPL October 2004
レノックス、他 規格はCPL2004年10月にRFC3880を追跡します[12ページ]。
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つの分野が、以下に定義されて、記載されています。 それぞれのこれらの分野の値は非重要構造が全く定義されていない自由形式ユニコードストリングです。
subject: The subject of the call.
subject: 呼び出しの対象。
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].
ストリングは大文字と小文字を区別しないユニコードストリングとして以下の方法で合わせられています。 まず最初に、ストリングはユニコードStandard Annex#15[5]で指定されるように「互換性構成」(KC)というフォームにcanonicalizedされます。 そして、ストリングは、ユニコードStandard Annex#21[6]で指定されるように現場の神経の鈍いcaselessマッピングを使用することで比較されます。
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では、第一歩を実行するコードは利用可能です。 UAX15[5]のAnnex5からリンクを見てください。 Java標準クラス図書館での大文字と小文字を区別しないストリング比較は既に第2ステップを実行します。 他のユニコード意識しているライブラリは同様であるべきです。
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.
マッチングが「ストリング」と命名されて、義務的な議論、1を持っているストリングの出力タグが「ある」か、または「含有」、全体のストリングマッチを示すか、またはサブストリングがそれぞれ合っています。
4.2.1. Usage of "string-switch" with SIP
4.2.1. 一口がある「ストリングスイッチ」の用法
For SIP, the fields "subject", "organization", and "user-agent" correspond to the SIP header fields with the same name. These are used verbatim as they appear in the message.
SIPに関しては、分野「対象」、「組織」、および「ユーザエージェント」は同じ名前でSIPヘッダーフィールドに対応しています。 自分達がメッセージに現れるようにこれらは逐語的に使用されます。
The field "display" is not used, and is never present.
分野「表示」は、使用されていなくて、また決して存在していません。
Lennox, et al. Standards Track [Page 13] RFC 3880 CPL October 2004
レノックス、他 規格はCPL2004年10月にRFC3880を追跡します[13ページ]。
4.3. Language Switches
4.3. 言語スイッチ
Language switches allow a CPL script to make decisions based on the languages in which the originator of the call wishes to communicate. They are summarized in Figure 6.
言語スイッチで、CPLスクリプトは呼び出しの創始者が交信したがっている言語に基づく決定をすることができます。 それらは図6にまとめられます。
Node: "language-switch"
Outputs: "language" Specific string to match
Parameters: None
ノード: 「言語スイッチ」出力: 「言語」SpecificはマッチParametersに以下を結びます。 なし
Output: "language"
Parameters: "matches" Match if the given language
matches a language-range of the
call.
出力: 「言語」パラメタ: 与えられた言語が呼び出しの言語範囲に合っているなら、Matchを「合わせます」。
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つのパラメタ、「マッチ」を取ります。 パラメタの値はRFC3066[7]で定義されるように言語タグです。 訪問者はまた、RFC3066で定義されるように1セットの言語範囲を指定したかもしれません。 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 "-".
言語範囲がどう言語タグに合うかに関する詳細に関してRFC3066を見てください。 簡潔に、まさにタグと等しい、またはまさにタグの接頭語と等しいなら、言語範囲は、接頭語に従う最初のキャラクタが「-」であるように言語タグに合っています。
If the caller specified the special language-range "*", it is ignored for the purpose of matching. Languages with a "q" value of 0 are also ignored.
訪問者が特別な言語範囲「*」を指定したなら、それはマッチングの目的のために無視されます。 また、0の「q」値がある言語は無視されます。
This switch MAY be not-present.
このスイッチは存在していないかもしれません。
4.3.1. Usage of "language-switch" with SIP
4.3.1. 一口がある「言語スイッチ」の用法
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」値、「言語を受け入れる、」 ヘッダーフィールドは無視されます。
Lennox, et al. Standards Track [Page 14] RFC 3880 CPL October 2004
レノックス、他 規格はCPL2004年10月にRFC3880を追跡します[14ページ]。
4.4. Time Switches
4.4. タイムスイッチ
Time switches allow a CPL script to make decisions based on the time and/or date the script is being executed. They are summarized in Figure 7.
タイムスイッチで、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
ノード: 「タイムスイッチ」出力: Parametersを合わせる「時間」Specific時間: "tzid"RFC2445時間帯の識別子"tzurl"RFC2445時間帯の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
出力: 「時間」パラメタ: 再発の発生の再発(2445年のRFC DATE-タイム誌)「カウント」Numberの再発(「一時間「第二に」と、「綿密に」と、」「毎日の」「毎週」、「月毎である」か、「毎年」)「間隔」Howしばしば再発反復“until" Boundの間隔(RFC2445DURATION)"freq"Frequencyの間隔(2445年のRFC DATE-タイム誌)「持続時間」Lengthの間隔(2445年のRFC DATE-タイム誌)"dtend"Endの"dtstart"Start; 値の"bysetpos"Listが中で決める出来事の労働週の"wkst"First日の年の何1年の"bymonth"Listの何週間もの1年の"byweekno"Listの何日もの月の"byyearday"Listの何日もの1週間"bymonthday"Listの何日もの1日"byday"Listの何時間もの"byhour"Listが指定した1時間以内の数分の微小な"byminute"Listの中の秒の"bysecond"List
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].
タイムスイッチはインターネットCalendaringとScheduling Core Object Specification(iCalendar COS)(RFC2445[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.
将来の標準化過程文書が発表されるなら、それらのドキュメントが再発取り扱いようにするどんなそのアップデートや、時代遅れのRFC2445や、変更やまたは明確化もまた、CPLタイムスイッチに適用されます。
Lennox, et al. Standards Track [Page 15] RFC 3880 CPL October 2004
レノックス、他 規格はCPL2004年10月にRFC3880を追跡します[15ページ]。
An algorithm to determine whether an instant falls within a given recurrence is given in Appendix A.
瞬間が与えられた再発の中で低下するか否かに関係なく、Appendix 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.
そして、「タイムスイッチ」タグがそれの両方がRFC2445で定義される2つの任意のパラメタ、"tzid"、および"tzurl"を取る、(セクション4.8.3、.1、4.8 .3 .5 それぞれ) "tzid"は時間帯の定義が参照をつけられる特定ラベルです。 前進のスラッシュ(ソリドゥス)で始まるなら、定義されたグローバルな時間帯の登録に参照をつけます。 さもなければ、それはサーバで局所的に定義されています。"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"ラベルは局所的に定義されますが、サーバが少なくともオルソンTime Zoneデータベース[9]によって使用される命名計画を支持するのは、RECOMMENDEDです。 オルソン計画を使用するタイムゾーンデータベースに関する例はほとんどのUnixのようなシステム、および標準のJava TimeZoneのクラスのzoneinfoファイルです。
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.
スクリプトがアップロードされるとき、サーバSHOULDは時間帯の定義の"tzid"と"tzurl"参照を決議します。 彼らは定期的に得る中で時間帯の定義最も最新であるこれらの解決をリフレッシュするかもしれません。 "tzurl"が無効になるなら、サーバSHOULDは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"でアップロードできないか、決議できません、それ。SHOULDはスクリプトアップロード時間にこれを診断して、拒絶します。 "tzid"も"tzurl"も存在していないなら、このタイムスイッチの中のすべての非UTC回が、すなわち、それらがCPLサーバのローカルのタイムゾーンで指定されるという「浮いている」回であるので解釈されるべきです。
Because of daylight-savings-time changes over the course of a
year, it is necessary to specify time switches in a given
timezone. UTC offsets are not sufficient, or a time-of-day
routing rule which held between 9 am and 5 pm in the eastern
United States would start holding between 8 am and 4 pm at the end
of October.
1年の過程にわたる日光貯蓄時刻変更のために、与えられたタイムゾーンでタイムスイッチを指定するのが必要です。 UTCオフセットが十分でないか、または東合衆国で午前9時と午後5時の間成立した時刻ルーティング規則は、10月の終わりに午前8時と午後4時の間成立し始めるでしょう。
Authors of CPL servers should be careful to handle correctly the intervals when local time is discontinuous, at the beginning or end of daylight-savings time. Note especially that some times may occur more than once when clocks are set back. The algorithm in Appendix A is believed to handle this correctly.
CPLサーバの作者は現地時間とき、正しく間隔を扱うのが不連続であるのに慎重であるはずです、日光貯蓄時間の始めか終わりに。 時計が遅らせられたら数回が一度より起こるかもしれないことに特に注意してください。 Appendix 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
時間ノードは彼らの出力が取られるべきである期間のリストを指定します。 彼らには、2つの必要なパラメタがあります: または"dtstart"、どれがリストの初潮、およびまさに"dtend"の1つの始まりを指定するか、そして、または「持続時間」。(それは、終了時刻を指定します)。
Lennox, et al. Standards Track [Page 16] RFC 3880 CPL October 2004
レノックス、他 規格はCPL2004年10月にRFC3880を追跡します[16ページ]。
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].
それぞれ期間の持続時間。 iCalendar COS DATE-タイム誌が評価するように"dtstart"と"dtend"パラメタはフォーマットされます、.5セクション4.3RFC2445[8]で指定されるように。 時間帯がトップレベル「タイムスイッチ」タグで指定されるので、フォーム1か2(浮動かUTC回)しか使用できません。 iCalendar COS DURATIONパラメタ、指定にされるとして.6セクション4.3RFC2445で「持続時間」パラメタを与えます。 DATE-タイム誌とDURATION構文の両方がISO8601[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"、および「持続時間」SHOULD NOTはそのようなパラメタが存在していた状態でCPLサーバSHOULDがスクリプトを受け入れますが、"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"パラメタは以下の値の1つを取ります: 期間が1秒以上の間隔に期間が「一時間」1分以上の間隔に1時間以上の間隔に基づく繰り返している期間を指定するために基礎づけた反復を指定するために「綿密に」基礎づけた反復を指定するためには、「第二に」「毎日」; 期間が1日以上の間隔に期間が1週間以上の間隔に1年以上の間隔に基づく繰り返している期間を指定するために「毎年1カ月以上の間隔、および」基づく繰り返している期間を指定するために「月毎に」基礎づけた反復を指定するために「毎週」基礎づけた反復を指定するために。 これらの値は大文字と小文字を区別していません。
The "interval" parameter contains a positive integer representing how often the recurrence rule repeats. The default value is "1", meaning every second for a "secondly" rule, every minute for a "minutely" rule, every hour for an "hourly" rule, every day for a "daily" rule, every week for a "weekly" rule, every month for a "monthly" rule, and every year for a "yearly" rule.
「間隔」パラメタはどれくらいの頻度で再発規則反復を表す正の整数を含んでいます。 デフォルト値は「「綿密に」という規則のための「第二に」という規則のためにあらゆる2番目を意味する毎分、「1時間ごと」の規則のための毎時間、「日刊誌」のための毎日が「毎週」の規則、「毎月」の規則のための毎月、および「年一度」の規則のための毎年間毎週、統治する1インチ」です。
The "until" parameter defines an iCalendar COS DATE or DATE-TIME value which bounds the recurrence rule in an inclusive manner. If the value specified by "until" is synchronized with the specified recurrence, this date or date-time becomes the last instance of the recurrence. If specified as a date-time value, then it MUST be
“until"パラメタは再発が包括的な方法でそれの領域を統治するiCalendar COS DATEかDATE-タイム誌値を定義します。 “until"によって指定された値が指定された再発と同期するなら、この日付か日付-時間が再発の最終審になります。 日付時間的価値として指定されるなら、それはそうであるに違いありません。
Lennox, et al. Standards Track [Page 17] RFC 3880 CPL October 2004
レノックス、他 規格はCPL2004年10月にRFC3880を追跡します[17ページ]。
specified in UTC time format. If not present, and the "count" parameter is not also present, the recurrence is considered to repeat forever.
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"パラメタは最初の発生にみなします。 “until"と「カウント」パラメタは同じ「時間」出力で現れてはいけません。
The "bysecond" parameter specifies a comma-separated list of seconds within a minute. Valid values are 0 to 59. The "byminute" parameter specifies a comma-separated list of minutes within an hour. Valid values are 0 to 59. The "byhour" parameter specifies a comma- separated list of hours of the day. Valid values are 0 to 23.
"bysecond"パラメタは1分以内に秒のコンマで切り離されたリストを指定します。 有効値は、0〜59です。 "byminute"パラメタは1時間以内に数分のコンマで切り離されたリストを指定します。 有効値は、0〜59です。 "byhour"パラメタは1日の何時間ものコンマの切り離されたリストを指定します。 有効値は、0〜23です。
The "byday" parameter specifies a comma-separated list of days of the week. "MO" indicates Monday, "TU" indicates Tuesday, "WE" indicates Wednesday, "TH" indicates Thursday, "FR" indicates Friday, "SA" indicates Saturday, and "SU" indicates Sunday. These values are not case-sensitive.
"byday"パラメタは週の数曜日のコンマで切り離されたリストを指定します。 「MO」は月曜日を示します、と「トゥ」は火曜日に示します、と「私たち」は水曜日に示します、と“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.
また、肯定(+ n)であるか否定している(-n)整数はそれぞれの"byday"値に先行できます。 存在しているなら、これは「毎月」の、または、「年一度」の再発の中に特定の日の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"パラメタは月の何日ものコンマで切り離されたリストを指定します。 有効値は、-31〜1〜31か-1です。 例えば、-10は月の最後の日まで10番目を表します。
The "byyearday" parameter specifies a comma-separated list of days of the year. Valid values are 1 to 366 or -366 to -1. For example, -1 represents the last day of the year (December 31st) and -306 represents the 306th to the last day of the year (March 1st).
"byyearday"パラメタは1年の何日ものコンマで切り離されたリストを指定します。 有効値は、-366〜1〜366か-1です。 例えば、-1は年(12月31日)の最後の日を表します、そして、-306は年(3月1日)の最後の日まで306番目を表します。
The "byweekno" parameter specifies a comma-separated list of ordinals specifying weeks of the year. Valid values are 1 to 53 or -53 to -1. This corresponds to weeks according to week numbering as defined in ISO 8601 [20]. A week is defined as a seven day period, starting on the day of the week defined to be the week start (see "wkst"). Week number one of the calendar year is the first week which contains at least four (4) days in that calendar year. This parameter is only valid for "yearly" rules. For example, 3 represents the third week of the year.
"byweekno"パラメタは年の週に指定する序数のコンマで切り離されたリストを指定します。 有効値は、-53〜1〜53か-1です。 週の付番に従って、これはISO8601[20]で定義されるように何週間も対応しています。 1週間は7日の期間と定義されます、週の始めになるように定義された曜日を始めて("wkst"を見てください)。 暦年の週のナンバーワンはその暦年に少なくとも4(4)日間を含む1週間目です。 「年一度」の規則だけに、このパラメタは有効です。 例えば、3は1年の3週間目を表します。
Lennox, et al. Standards Track [Page 18] RFC 3880 CPL October 2004
レノックス、他 規格はCPL2004年10月にRFC3880を追跡します[18ページ]。
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年の何カ月ものコンマで切り離されたリストを指定します。 有効値は、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"パラメタは労働週1日を指定します。 有効値は、「MO」と、「トゥ」と、「私たち」と、“TH"と、「フラン」と、"SA"と"SU"です。 「毎週」の再発に間隔より多くの1があるとき、これは重要です、そして、"byday"パラメタは指定されます。 また、"byweekno"パラメタが指定されるとき、これも「年一度」の再発で重要です。 デフォルト値は「MO」、次のISO8601[20]です。
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番目の発生に対応する値のコンマで切り離されたリストを指定します。 有効値は、-366〜1〜366か-1です。 別の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=、「2月の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インチは1月に再発インスタンスの数を減少すること」と等しいです。 しばらく、一般に、頻度が再発の反復回数を増強するか、または広くするほどパラメタをByxxxしません。 例えば、「年一度」のfreq=bymonthは「1、2インチは年一度の再発セットの中で1から何日もの数を2まで増強("bymonth"パラメタが存在していないなら)」と等しいです。
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"。 そして、「カウント」と“until"は評価されます。
Lennox, et al. Standards Track [Page 19] RFC 3880 CPL October 2004
レノックス、他 規格はCPL2004年10月にRFC3880を追跡します[19ページ]。
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">
"SU"「年一度」の「10M」の<時間dtstart="19970105T083000"持続時間=freq=間隔=の「2インチのbymonth=」の1インチのbyday=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時と1月午前9時(隔年)」に到着するように適用されるでしょう」。 次に、byminute=「30インチは「毎週日曜日の午前8時30分と1月午前9時30分(隔年)」に到着するように適用されるでしょう」。 2番目が「午前8時30分0秒から午前8時40分0秒まで午前9時40分0秒と午前9時30分0秒から午前9時40分0秒までの1月の毎週日曜日、隔年」のときに終わるために"dtstart"から得られるその時。 同様に、"byminute"、"byhour"、"byday"、"bymonthday"、または"bymonth"パラメタがなくなるなら、"dtstart"パラメタから適切な分、時間、日、または月を検索してあるでしょうに。
The iCalendar COS RDATE, EXRULE, and EXDATE recurrence rules are not specifically mapped to components of the time-switch node. Equivalent functionality to the exception rules can be attained by using the ordering of switch rules to exclude times using earlier rules; equivalent functionality to the additional-date RDATE rules can be attained by using "sub" nodes (see Section 8) to link multiple outputs to the same subsequent node.
iCalendar COS RDATE、EXRULE、およびEXDATE再発規則は明確にタイムスイッチノードの成分に写像されません。 以前の規則を使用することで回を除くのにスイッチ規則の注文を使用することによって、例外の原則への同等な機能性に達することができます。 同じその後のノードに複数の出力をリンクするのに、「潜水艦」ノード(セクション8を見る)を使用することによって、追加期日のRDATE規則への同等な機能性に達することができます。
The "not-present" output is never true for a time switch. However, it MAY be included to allow switch processing to be more regular.
タイムスイッチには、「プレゼントでない」出力は決して本当ではありません。 しかしながら、スイッチ処理が、より定期的であることを許容するのは含まれるかもしれません。
4.4.1. iCalendar Differences and Implementation Issues
4.4.1. iCalendar差と導入問題
(This sub-sub-section is non-normative.)
(このサブ小区分は非規範的です。)
The specification of recurring events in this section is identical (except for syntax and formatting issues) to that of RFC 2445 [8], with only one additional restriction. That one restriction is that consecutive instances of recurrence intervals may not overlap.
このセクションの繰り返し起こる事柄の仕様はRFC2445[8]のものと同じです(構文と形式問題を除いた)、1つの追加制限だけで。 その1つの制限は再発間隔の連続したインスタンスが重ならないかもしれないということです。
It was a matter of some debate, during the design of CPL, whether the entire iCalendar COS recurrence specification should be included in CPL, or whether only a subset should be included. It was eventually decided that compatibility between the two protocols was of primary importance. This imposes some additional implementation issues on implementors of CPL servers.
それは何らかの討論の問題でした、CPLのデザインの間、全体のiCalendar COS再発仕様がCPLに含まれるべきであるか、または部分集合だけが含まれるべきであることにかかわらず。 結局、2つのプロトコルの間の互換性がプライマリに重要であったと決められました。 これはいくつかの追加導入問題をCPLサーバの作成者に課します。
Lennox, et al. Standards Track [Page 20] RFC 3880 CPL October 2004
レノックス、他 規格はCPL2004年10月にRFC3880を追跡します[20ページ]。
It does not appear to be possible to determine, in constant time, whether a given instant of time falls within one of the intervals defined by a full iCalendar COS recurrence. The primary concerns are as follows:
それは決定するのにおいて可能であるように見えません、一定の時間で、時間の与えられた瞬間が完全なiCalendar COS再発で定義された間隔の1つ中に低下するか否かに関係なく。 プライマリ関心は以下の通りです:
o The "count" parameter cannot be checked in constant running
time, since it requires that the server enumerate all
recurrences from "dtstart" to the present time, in order to
determine whether the current recurrence satisfies the
parameter. However, a server can expand a "count" parameter
once, off-line, to determine the date of the last recurrence.
This date can then be treated as a virtual "until" parameter
for the server's internal processing.
o 一定の実行時間で「カウント」パラメタをチェックできません、サーバがすべての"dtstart"から現在までの再発を列挙するのが必要であるので、現在の再発がパラメタを満たすかどうか決定するために。 しかしながら、サーバは、最後の再発の日付を決定するために「カウント」パラメタを一度オフラインで広くすることができます。 そして、サーバの内部の処理のための仮想の“until"パラメタとしてこの日付を扱うことができます。
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.
Appendix 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スクリプトがとんでもないほど大きくないのをチェックするべきであるようにするものを拒絶するべきです。
4.5. Priority Switches
4.5. 優先権スイッチ
Priority switches allow a CPL script to make decisions based on the priority specified for the original call. They are summarized in Figure 8. They are dependent on the underlying signalling protocol.
優先権スイッチで、CPLスクリプトはオリジナルの呼び出しに指定された優先権に基づく決定をすることができます。 それらは図8にまとめられます。 それらは基本的な合図プロトコルに依存しています。
Lennox, et al. Standards Track [Page 21] RFC 3880 CPL October 2004
レノックス、他 規格はCPL2004年10月にRFC3880を追跡します[21ページ]。
Node: "priority-switch"
Outputs: "priority" Specific priority to match
Parameters: None
ノード: 「優先権スイッチ」出力: Parametersを合わせる「優先権」Specific優先権: なし
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
出力: 「優先権」パラメタ: 「より少ない」Matchが優先権がそれ以下であるなら優先権が優先権が等しいならそれが「等しい」Matchを指定したより大きいなら「よりすばらしい」Matchを指定しました。
Figure 8: Syntax of the "priority-switch" node
エイト環: 「優先権スイッチ」ノードの構文
Priority switches take no parameters.
優先権スイッチはパラメタを全く取りません。
The "priority" tag takes one of the three parameters "greater", "less", or "equal". The values of these parameters are one of the following priorities: in decreasing order, "emergency", "urgent", "normal", and "non-urgent". These values are matched in a case- insensitive manner. Outputs with the "less" parameter are taken if the priority of the call is less than the priority given in the argument, and so forth.
「優先権」タグは3つのパラメタ「よりすばらしい」か、「以下」、または「同輩」の1つを取ります。 これらのパラメタの値は以下のプライオリティの1つです: 減少では、「緊急」の、そして、「正常で」、「不急」の「非常時」よう命令してください。 これらの値はケースの神経の鈍い方法で合わせられています。 呼び出しの優先権が議論、などに与えられた優先以下であるなら「より少ない」パラメタがある出力を取ります。
If no priority is specified in a message, the priority is considered to be "normal". If an unknown priority is specified in the call, it is considered to be equivalent to "normal" for the purposes of "greater" and "less" comparisons, but it is compared literally for "equal" comparisons.
優先権が全くメッセージで指定されないなら、優先権が「正常である」と考えられます。 未知の優先が呼び出しで指定されるなら、「よりすばらしく」て「より少ない」比較の目的のために「標準」に相当していると考えられますが、それは文字通り「等しい」比較のために比較されます。
Since every message has a priority, the "not-present" output is never true for a priority switch. However, it MAY be included, to allow switch processing to be more regular.
あらゆるメッセージには優先があるので、優先権スイッチには、「プレゼントでない」出力は決して本当ではありません。 しかしながら、それは、スイッチ処理が、より定期的であることを許容するために含まれるかもしれません。
4.5.1. Usage of "priority-switch" with SIP
4.5.1. 一口がある「優先権スイッチ」の用法
The priority of a SIP message corresponds to the "Priority" header in the initial "INVITE" message.
SIPメッセージの優先権は初期の「招待」メッセージの「優先権」ヘッダーに文通されます。
5. Location Modifiers
5. 位置の修飾語
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では、定義される)の振舞いは指定された現在のロケーションセットに依存しています。 位置のノードは、ロケーションセットから位置を加えるか、または取り除きます。
Lennox, et al. Standards Track [Page 22] RFC 3880 CPL October 2004
レノックス、他 規格はCPL2004年10月にRFC3880を追跡します[22ページ]。
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つのタイプがあります。 明白な位置は文字通り指定された位置を現在のロケーションセットに加えます、そして、位置のルックアップは外部のソースから位置を得ます、そして、位置のフィルタはセットから位置を移します、いくつかの指定された評価基準に基づいて。
5.1. Explicit Location
5.1. 明白な位置
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
ノード: 「位置」出力: なにも、次の(次のノードは直接続きます)ノード: どんなノードParametersも: 新しい価値を高める前にロケーションセットをきれいにするためにこの位置(0.0-1.0)の「クリアしてください」Whetherのロケーションセット「優先権」Priorityに加えるアドレスの"url"URL
Figure 9: Syntax of the "location" node
図9: 「位置」ノードの構文
Explicit location nodes have three node parameters. The mandatory "url" parameter's value is the URL of the address to add to the location set. Only one address may be specified per location node; multiple locations may be specified by cascading these nodes.
明白な位置のノードには、3つのノードパラメタがあります。 義務的な"url"パラメタの値はロケーションセットに加えるアドレスのURLです。 位置のノード単位で1つのアドレスだけを指定してもよいです。 複数の所在地は、これらのノードをどっと落させることによって、指定されるかもしれません。
The optional "priority" parameter specifies a priority for the location. Its value is a floating-point number between 0.0 and 1.0. If it is not specified, the server SHOULD assume a default priority of 1.0. The optional "clear" parameter specifies whether the location set should be cleared before adding the new location to it. Its value can be "yes" or "no", with "no" as the default.
任意の「優先権」パラメタは位置に優先を指定します。 値は0.0〜1.0の浮動小数点の数です。 それが指定されないなら、サーバSHOULDは、デフォルトが1.0の優先権であると仮定します。 任意の「明確な」パラメタは、新しい位置をそれに加える前にロケーションセットがきれいにされるべきであるかどうか指定します。 値は、デフォルトとして「はい」か「いいえ」がある「いいえ」であることができます。
Basic location nodes have only one possible result, since there is no way that they can fail. (If a basic location node specifies a location which isn't supported by the underlying signalling protocol, the script server SHOULD detect this and report it to the user at the time the script is submitted.) Therefore, their XML representations do not have explicit output tags; the <location> tag directly contains another node.
それらが失敗できる方法が全くないので、基本の位置のノードには、1つの可能な結果しかありません。 (基本の位置のノードが基本的な合図プロトコルによってサポートされない位置を指定するなら、スクリプトを提出するとき、スクリプトサーバSHOULDはユーザにこれを検出して、それを報告します。) したがって、彼らのXML表現には、明白な出力タグがありません。 <位置の>タグは直接別のノードを含んでいます。
5.1.1. Usage of "location" with SIP
5.1.1. 一口がある「位置」の用法
All SIP locations are represented as URLs, so the locations specified in "location" tags are interpreted directly.
すべてのSIP位置がURLとして表されるので、「位置」タグで指定された位置は直接解釈されます。
Lennox, et al. Standards Track [Page 23] RFC 3880 CPL October 2004
レノックス、他 規格はCPL2004年10月にRFC3880を追跡します[23ページ]。
5.2. Location Lookup
5.2. 位置のルックアップ
Locations can also be specified up through external means, through the use of location lookups. The syntax of these tags is given in Figure 10.
また、外部の手段、位置のルックアップの使用を通して位置を指定できます。 図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
ノード: 「ルックアップ」出力: 「成功」Nextノードによって、ルックアップであるならルックアップがうまくいっている"notfound"NextノードであったならルックアップがParametersに失敗したならどんなアドレスも「失敗」Nextノードでないことがわかりました: 新しい値を加える前にルックアップの「明確な」Whetherに見切りをつける前にロケーションセットをきれいにしようとするルックアップ「タイムアウト」Timeの「ソース」Source
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であるなら、CPLサーバがuriテキスト/リストメディアでオブジェクトを入手するために質問できる位置がタイプされるのを示します。(このタイプ(また、RFC2483[10])に現れるもの)のIANA登録を見てください。 追加情報(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ベースのソースを許容するのを拒否するかもしれません。 この場合それら、SHOULDはスクリプトアップロード時間にスクリプトを拒絶します。
There has been discussion of having CPL servers add URI parameters
to the location request, so that (for instance) CGI scripts could
be used to resolve them. However, the consensus was that this
should be a CPL extension, not a part of the base specification.
CPLサーバにURIパラメタを位置の要求に追加させる議論がありました、それらを決議するのに(例えば)CGIスクリプトを使用できるように。 しかしながら、コンセンサスはこれが基礎仕様の一部ではなく、CPL拡張子であるべきであるということでした。
Lennox, et al. Standards Track [Page 24] RFC 3880 CPL October 2004
レノックス、他 規格はCPL2004年10月にRFC3880を追跡します[24ページ]。
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.
ルックアップには、3回の出力があります: 「成功」、"notfound"、および「失敗。」 Notfoundはルックアッププロセスが成功したなら取りましたが、少しの位置も見つけませんでした。 ルックアップがある理由で失敗したなら、失敗を取って、それを含んでいて、指定されたタイムアウトを超えていました。 与えられた出力が存在していないなら、実行が終えるスクリプトとデフォルトの振舞いは実行されます。
5.2.1. Usage of "lookup" with SIP
5.2.1. 一口がある「ルックアップ」の用法
For SIP, the "registration" lookup source corresponds to the locations registered with the server using "REGISTER" messages.
SIPに関しては、「登録」ルックアップソースは「レジスタ」メッセージを使用するサーバに登録された位置に文通しています。
5.3. Location Removal
5.3. 位置の取り外し
A CPL script can also remove locations from the location set, through the use of the "remove-location" node. The syntax of this node is defined in Figure 11.
また、A 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
ノード: 「位置を取り外す、」 出力: なにも、次の(次のノードは直接続きます)ノード: どんなノードParametersも: 取り外す「位置」Location
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を与えます。 このパラメタを与えないなら、セットからすべての位置を取り除きます。
Lennox, et al. Standards Track [Page 25] RFC 3880 CPL October 2004
レノックス、他 規格はCPL2004年10月にRFC3880を追跡します[25ページ]。
The "remove-location" node has no explicit output tags. In the XML syntax, the XML "remove-location" tag directly encloses the next node's tag.
「位置を取り外す、」 ノードには、どんな明白な出力タグもありません。 XML構文、XML、「位置を取り外す、」 タグは直接次のノードのタグを同封します。
5.3.1. Usage of "remove-location" with SIP
5.3.1. 用法、「位置を取り外す、」、一口
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マッチング(例えば、使用されている登録証明書をリフレッシュするときContactが扱うマッチへの)に標準の規則を使用することでロケーションセットに取り組まされます。
6. Signalling Operations
6. 合図操作
Signalling operation nodes cause signalling events in the underlying signalling protocol. Three signalling operations are defined: "proxy," "redirect," and "reject."
合図操作ノードは基本的な合図プロトコルの合図イベントを引き起こします。 3つの合図操作が定義されます: 「プロキシ」、「再直接」、および「廃棄物。」
6.1. Proxy
6.1. プロキシ
Proxy causes the triggering call to be forwarded on to the currently specified set of locations. The syntax of the proxy node is given in Figure 12.
プロキシは現在指定されたセットの位置に送られるという引き金となる要求を引き起こします。 図12でプロキシノードの構文を与えます。
The specific signalling events invoked by the "proxy" node are signalling-protocol-dependent, though the general concept should apply to any signalling protocol.
「プロキシ」ノードによって呼び出された特定の合図イベントは合図プロトコル扶養家族です、一般概念がどんな合図プロトコルにも適用されるべきですが。
Lennox, et al. Standards Track [Page 26] RFC 3880 CPL October 2004
レノックス、他 規格はCPL2004年10月にRFC3880を追跡します[26ページ]。
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"Nextノードを返したなら、タイムアウト「リダイレクション」Nextノードが呼び出し試みであるなら呼び出し試みが向け直された「失敗」Nextノードであったなら不特定の出力Parametersのために次の「デフォルト」Defaultノードに失敗する前に「忙しい」Nextノードは答えられませんでした: 呼び出しに見切りをつける前に試みる「タイムアウト」Timeは、「注文」Whatがロケーションセットを試すために注文するリダイレクションを再帰的に見上げるために"「再-呪い」"Whetherを試みます。
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).
上記の状態の1つが本当ですが、対応する出力が指定されなかったなら、「プロキシ」ノードの「デフォルト」出力は代わりに続かれています。 また、指定された「デフォルト」ノードが全くなければ、CPL実行が終わって、サーバがデフォルトの振舞いに戻る、(通常、最も良い応答上流を創始者に送る、)
Lennox, et al. Standards Track [Page 27] RFC 3880 CPL October 2004
レノックス、他 規格はCPL2004年10月にRFC3880を追跡します[27ページ]。
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.
どんな位置もセット、またはセットにおける唯一の位置であるならサーバがそうすることができない位置がプロキシa要求(例えば、"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秒です。 さもなければ、サーバSHOULDは時間の適度に長い期間、鳴るという要求(サーバ方針が許容する最大の範囲への)を許します。
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つの値、「はい」または「いいえ」を取ることができる"「再-呪い」"です。 これは、サーバが、初期のサーバから返されたリダイレクション応答でさらなる呼び出し試みを電話アドレスに置くのを自動的に試みるべきであるかどうか指定します。スクリプトへの「リダイレクション」出力が"「再-呪い」"の値が「はい」であるなら、決して取られないことに注意してください。 この場合、これはSHOULD NOTを出力しました。存在してください。 このパラメタのデフォルト値は「はい」です。
The third optional parameter is "ordering". This can have three possible values: "parallel", "sequential", and "first-only". This parameter specifies in what order the locations of the location set should be tried. Parallel asks that they all be tried simultaneously; sequential asks that the one with the highest priority be tried first, the one with the next-highest priority second, and so forth, until one succeeds or the set is exhausted. First-only instructs the server to try only the highest-priority address in the set, and then follow one of the outputs. The priority of locations in a set is determined by server policy, though CPL servers SHOULD honor the "priority" parameter of the "location" tag. The default value of this parameter is "parallel".
3番目の任意のパラメタは「注文されています」。 これは3つの可能な値を持つことができます: 「平行」、「連続する」、および「1番目専用。」 このパラメタは、ロケーションセットの位置がどんなオーダーで試みられるべきであるかを指定します。 平行は、それらが皆、同時に試みられるように頼みます。 連続する、最優先が最初に試みられているもの、次の最優先2番目1時までのなどがあるものが成功するか、またはセットが消耗していると尋ねます。 1番目だけがセットで最優先するアドレスだけを試みて、次に、出力の1つに続くようサーバに命令します。 セットにおける、位置の優先権はサーバ方針で決定します、CPLサーバSHOULDが「位置」タグの「優先権」パラメタを光栄に思いますが。 このパラメタのデフォルト値は「平行です」。
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.
コントロールが他のノードに通過されるなら、一度、プロキシ操作は使用されたすべての位置を完成します。ロケーションセットから、クリアされます。 「注文」が「平行である」か「連続した」なら、すなわち、ロケーションセットは「プロキシ-可能」位置について空にされています。 セットにおける最優先する商品は「注文」が「1番目専用」であったならセットから取り外されます。 (すべての場合では、"http"URIなどの非「プロキシ-可能」位置は残っています。) そして、「リダイレクション」出力の場合では、呼び出しが向け直された新しいアドレスはロケーションセットに加えられます。
Lennox, et al. Standards Track [Page 28] RFC 3880 CPL October 2004
レノックス、他 規格はCPL2004年10月にRFC3880を追跡します[28ページ]。
6.1.1. Usage of "proxy" with SIP
6.1.1. 一口がある「プロキシ」の用法
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サーバSHOULDはSIP登録証明書の「q」パラメタを光栄に思います。
6.2. Redirect
6.2. 再直接
Redirect causes the server to direct the calling party to attempt to place its call to the currently specified set of locations. The syntax of this node is specified in Figure 13.
原因を向け直してください。電話を現在指定されたセットの位置にするのを試みるよう起呼側に指示するサーバ。 このノードの構文は図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
ノード: 「再直接」の出力: なにも、次の(どんなノードも続かないかもしれません)ノード: なにも、パラメタ: 「永久的な」Whether、リダイレクションは永久的であると考えられるべきです。
Figure 13: Syntax of the "redirect" node
図13: 「再直接」のノードの構文
Redirect immediately terminates execution of the CPL script, so this node has no outputs and no next node. It has one parameter, "permanent", which specifies whether the result returned should indicate that this is a permanent redirection. The value of this parameter is either "yes" or "no" and its default value is "no."
再直接、CPLスクリプトの実行がすぐに終わるので、このノードには、出力がなくて次ノードが全くありません。 それには、1つのパラメタがあって、「永久的であること」で、どれが、結果が戻ったかどうか指定するかがこれが永久的なリダイレクションであることを示すべきです。 このパラメタの値は、「はい」か「いいえ」のどちらかです、そして、デフォルト値は「いいえ」です。
Lennox, et al. Standards Track [Page 29] RFC 3880 CPL October 2004
レノックス、他 規格はCPL2004年10月にRFC3880を追跡します[29ページ]。
6.2.1. Usage of "redirect" with SIP
6.2.1. 一口がある「再直接」の用法
The SIP server SHOULD send a 3xx class response to a call request upon executing a "redirect" tag. If "permanent" was "yes", the server SHOULD send the response "301" (Moved permanently), otherwise it SHOULD send "302" (Moved temporarily).
SIPサーバSHOULDは「再直接」のタグを実行することに関する発呼要求への3xxクラス応答を送ります。 「永久的である」なら、「はい」、SHOULDが送るサーバは応答「301」でした(永久に、動かされます)。さもなければ、それは「302」(一時動かされる)を送るべきです。
6.3. Reject
6.3. 廃棄物
Reject nodes cause the server to reject the call attempt. Their syntax is given in Figure 14. The specific behavior they invoke is dependent on the underlying signalling protocol involved, though their semantics are generally applicable.
廃棄物ノードで、サーバは呼び出し試みを拒絶します。 図14でそれらの構文を与えます。 彼らが呼び出す特異的行動はそれらの意味論が一般に適切ですが、かかわる基本的な合図プロトコルに依存しています。
Node: "reject"
Outputs: None (No node may follow)
Next node: None
Parameters: "status" Status code to return
"reason" Reason phrase to return
ノード: 「廃棄物」出力: なにも、次の(どんなノードも続かないかもしれません)ノード: なにも、パラメタ: StatusがReasonが戻るために言葉で表す「理由」を返すためにコード化する「状態」
Figure 14: Syntax of the "reject" node
図14: 「廃棄物」ノードの構文
A reject node immediately terminates the execution of a CPL script, so this node has no outputs and no next node.
廃棄物ノードがすぐにCPLスクリプトの実行を終えるので、このノードには、出力がなくて次のノードが全くありません。
This node has two arguments: "status" and "reason". The "status" argument is required, and can take one of the values "busy", "notfound", "reject", "error", or a signalling-protocol-defined status.
このノードには、2つの議論があります: 「状態」と「理由。」 「状態」議論は、必要であり、「忙しい」"notfound"が「拒絶する」値の1つ、「誤り」、または定義された合図プロトコル状態を取ることができます。
The "reason" argument optionally allows the script to specify a reason for the rejection.
「理由」議論で、スクリプトは任意に拒絶の理由を指定できます。
6.3.1. Usage of "reject" with SIP
6.3.1. 一口がある「廃棄物」の用法
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 SHOULDを実装するサーバは、「状態」分野が4xx、5xx、または6xx範囲のSIP状態に対応する数値議論であることを許容します。
They SHOULD send the "reason" parameter in the SIP reason phrase.
それら、SHOULDはSIP理由句の「理由」パラメタを送ります。
A suggested mapping of the named statuses is as follows. Servers MAY use a different mapping, though similar semantics SHOULD be preserved.
命名された状態の提案されたマッピングは以下の通りです。 サーバは異なったマッピングを使用するかもしれなくて、同様の意味論SHOULDですが、保存されてください。
"busy": 486 Busy Here
「忙しくします」: 486はここで忙しくします。
"notfound": 404 Not Found
"notfound": 見つけられなかった404
Lennox, et al. Standards Track [Page 30] RFC 3880 CPL October 2004
レノックス、他 規格はCPL2004年10月にRFC3880を追跡します[30ページ]。
"reject": 603 Decline
「廃棄物」: 603衰退
"error": 500 Internal Server Error
「誤り」: 500 内部サーバーエラー
7. Non-signalling Operations
7. 非合図操作
In addition to the signalling operations, CPL defines several operations which do not affect and are not dependent on the telephony signalling protocol.
合図操作に加えて、CPLはどんな感情もしていない、また電話合図プロトコルに依存しないいくつかの操作を定義します。
7.1. Mail
7.1. メール
The mail node causes the server to notify a user of the status of the CPL script through electronic mail. Its syntax is given in Figure 15.
メールノードで、サーバは電子メールを通して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
ノード: 「メール」出力: なにも、次の(次のノードは直接続きます)ノード: どんなノードParametersも: メールが送られるべきである"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.
「メール」ノードは1つの議論を取ります: アドレスを与える"mailto"URL、および送られるメールのどんな追加必要なパラメタ。 サーバは与えられたurlに内容を含むメッセージを送ります。 それ、また、SHOULDは通知時点で、オリジナルの発呼要求と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" />.
まさしくEメールアドレスよりむしろ完全な"mailto"URLを使用するのは、追加メールヘッダーが指定されるのを許容します、「ルックアップmailto: jones@example.com?subject =%20failed」<メールurl=/>などのように。
A mail node has only one possible result, since failure of e-mail delivery cannot reliably be known in real time. Therefore, its XML representation does not have output tags: the <mail> tag directly contains another node tag.
リアルタイムでメール配送の失敗を確かに知ることができないので、メールノードには、1つの可能な結果しかありません。 したがって、XML表現には、出力タグがありません: <メール>タグは直接別のノードタグを含んでいます。
Note that the syntax of XML requires that ampersand characters, "&", which are used as parameter separators in "mailto" URLs, be quoted as "&" inside parameter values (see Section C.12 of the XML specification [2]).
XMLの構文が、アンパーサンドキャラクタ、“&"("mailto"URLのパラメタ分離符として使用される)が"&"としてパラメタ値の中で引用されるのを必要とすることに注意してください。(XML仕様[2])のセクションC.12を見てください。
Lennox, et al. Standards Track [Page 31] RFC 3880 CPL October 2004
レノックス、他 規格はCPL2004年10月にRFC3880を追跡します[31ページ]。
7.1.1. Suggested Content of Mailed Information
7.1.1. 郵送された情報の提案された内容
This section presents suggested guidelines for the mail sent as a result of the "mail" node, for requests triggered by SIP. The message mailed (triggered by any protocol) SHOULD contain all this information, but servers MAY elect to use a different format.
このセクションは「メール」ノードの結果、送られたメールのための提案されたガイドラインを提示します、SIPによって引き起こされた要求のために。 メッセージの郵送された(どんなプロトコルでも、引き起こされる)SHOULDはこのすべての情報を含んでいますが、サーバは、異なった形式を使用するのを選ぶかもしれません。
1. If the "mailto" URI did not specify a subject header, the
subject of the e-mail is "[CPL]", followed by the subject
header of the SIP request. If the URI specified a subject
header, it is used instead.
1. "mailto"URIが対象のヘッダーを指定しなかったなら、メールの対象は一口要求の対象のヘッダーによっていうことになられた「[CPL]」です。 URIが対象のヘッダーを指定したなら、それは代わりに使用されます。
2. The "From" field of the e-mail is set to a CPL server
configured address, overriding any "From" field in the "mailto"
URI.
2. メールの“From"分野はCPLサーバへのセットがアドレスを構成しました、"mailto"URIにおけるどんな“From"分野もくつがえしてことです。
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"ヘッダー: URIはURI体系を剥取ることによって、Eメールアドレスに変換されるでしょう)。
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がボディーを指定するなら、使用されています。 訪問者(訪問者のディスプレイ名とアドレスの両方)と日付と時刻、呼び出し対象、利用可能であり、なにも指定されなかったなら、ボディーSHOULDは少なくともアイデンティティを含んでいます、呼び出し優先権。
The server SHOULD honor the user's requested languages, and send the mail notification using an appropriate language and character set.
サーバSHOULDは、ユーザの要求された言語を光栄に思って、適切な言語と文字集合を使用することでメール通知を送ります。
7.2. Log
7.2. ログ
The Log node causes the server to log information about the call to non-volatile storage. Its syntax is specified in Figure 16.
Logノードで、サーバは非揮発性記憶装置に呼び出しの情報を登録します。 構文は図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
ノード: 「ログ」出力: なにも、次の(次のノードは直接続きます)ノード: どんなノードParametersも: ログファイルに置かれるのに「コメント」Commentを使用するログファイルの「名前」Name
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,
ログはともに任意の状態で2つの議論を取ります: (それは、ログの名前を指定します)。「名前」と「コメント。」(それは、登録される情報に関してコメントを与えます)。 また、サーバSHOULDは登録されたイベントの時間などのログに他の情報を含んでいます。
Lennox, et al. Standards Track [Page 32] RFC 3880 CPL October 2004
レノックス、他 規格はCPL2004年10月にRFC3880を追跡します[32ページ]。
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.
登録されるという要求の引き金となった情報など。 イベントを登録したスクリプトの所有者にとって、ログは特定です。 「名前」パラメタが与えられないなら、イベントはスクリプト所有者のために標準の、そして、サーバで定義されたログファイルに登録されます。 この仕様はサーバからユーザがどう彼らのログを検索するかもしれないかを定義しません。
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サーバSHOULD NOTは直接ローカルファイル名に非解釈されたログ名を写像します、安全保障上の理由で、セキュリティ重要なファイルが上書きされるといけないので。
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.
SHOULD NOTが「ログ」イベントに失敗される正しく稼働しているCPLサーバ。 そういうものとして、ログノードは1つの可能な結果しか持つことができません、そして、彼らのXML表現には、明白な出力タグがありません。 CPL<ログ>タグは直接別のノードタグを含んでいます。
8. Subactions
8. Subactions
XML syntax defines a tree. To allow more general call flow diagrams, and to allow script re-use and modularity, we define subactions.
XML構文は木を定義します。 より多くの一般通話フローチャートを許容して、スクリプト再使用とモジュール方式を許容するために、私たちは副動作を定義します。
Two tags are defined for subactions: subaction definitions and subaction references. Their syntax is given in Figure 17.
2個のタグが副動作のために定義されます: 副動作定義と副動作参照。 図17でそれらの構文を与えます。
Tag: "subaction"
Subtags: Any node
Parameters: "id" Name of this subaction
以下にタグ付けをしてください。 "副動作"Subtags: どんなノードParametersも: この副動作の「イド」Name
Pseudo-node: "sub"
Outputs: None in XML tree
Parameters: "ref" Name of subaction to execute
疑似ノード: 「潜水艦」出力: XML木のParametersのなにも: 副動作の「審判」Name、実行します。
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.
Subactionsは"副動作"タグを通して定義されます。 これらのタグはどんな補助的情報(セクション9を見る)の後にもCPLスクリプトに置かれますが、どんなトップレベルタグの前にも置かれます。 彼らは1つの議論を取ります: 「イド」、副動作のためにスクリプトに選ばれた名前を示すトークン。 スクリプトによるあらゆる"副動作"タグのための「イド」値はそのスクリプトの中でユニークであるに違いありません。
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.
Subactionsは「潜水艦」タグから呼ばれます。 「潜水艦」タグは、「疑似ノード」であり、正しいノードがあるかもしれないCPL動作でどこへでも使用されていた状態で使用できます。 呼ばれるのに1つのパラメタ、「審判」に副動作の名前を要します。 「潜水艦」タグはそれ自身の出力ではなく、代わりに制御パスを副動作に含んでいます。
Lennox, et al. Standards Track [Page 33] RFC 3880 CPL October 2004
レノックス、他 規格はCPL2004年10月にRFC3880を追跡します[33ページ]。
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.
Subaction 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]を使用するべきです。 外部のリンクがあるとき終了を確実にするのは、難問です。
9. Ancillary Information
9. 補助的情報
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拡張子に必要であることがわかっていて、それはSHOULDです。このタグの中に置かれます。
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
以下にタグ付けをしてください。 「付属」のパラメタ: Subtagsのいずれも:でない なし
Figure 18: Syntax of the "ancillary" tag
図18: 「付属」のタグの構文
Lennox, et al. Standards Track [Page 34] RFC 3880 CPL October 2004
レノックス、他 規格はCPL2004年10月にRFC3880を追跡します[34ページ]。
10. Default Behavior
10. デフォルトの振舞い
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.
以前に取られたプロキシ操作: 基本的な合図プロトコルの規則に従ってこの位まで呼び出しへのすべての蓄積された応答のものであるどんな「最も良さ」応答も返してください。
11. CPL Extensions
11. CPL拡張子
Servers MAY support additional CPL features beyond those listed in this document. Some of the extensions which have been suggested are a means of querying how a call has been authenticated, richer control over H.323 addressing, end-system or administrator-specific features, regular-expression matching for strings and addresses, and mid-call or end-of-call controls.
サーバは本書では記載されたものを超えて追加CPLの特徴をサポートするかもしれません。 示された拡大のいくつかは、呼び出しがどう認証されたかを質問する手段かH.323アドレシングの、より豊かなコントロールかエンドシステムか管理者特有の特徴と、ストリングとアドレスのために合っている正規表現と、中間の呼び出しか呼び出しのエンドコントロールです。
CPL extensions are indicated by XML namespaces [11]. Every extension MUST have an appropriate XML namespace assigned to it. The XML namespace of the extension MUST be different from the XML namespace
CPL拡張子はXML名前空間[11]によって示されます。 あらゆる拡大で、適切なXML名前空間をそれに割り当てなければなりません。 拡大のXML名前空間はXML名前空間と異なっているに違いありません。
Lennox, et al. Standards Track [Page 35] RFC 3880 CPL October 2004
レノックス、他 規格はCPL2004年10月にRFC3880を追跡します[35ページ]。
defined in Section 14. The extension MUST NOT change the syntax or semantics of the CPL schema defined in this document. All XML tags and attributes that are part of the extension MUST be appropriately qualified so as to place them within that namespace.
セクション14では、定義されます。 拡大は本書では定義されたCPL図式の構文か意味論を変えてはいけません。 その名前空間の中にそれらを置くために適切にすべてのXMLタグと拡大の一部である属性に資格がなければなりません。
Tags or attributes in a CPL script which are in the global namespace (i.e., not associated with any namespace) are equivalent to tags and attributes in the CPL namespace "urn:ietf:params:xml:ns:cpl".
グローバルな名前空間(すなわち、どんな名前空間にはも、交際しない)にあるCPLスクリプトによるタグか属性がCPL名前空間「つぼ:ietf:params:xml:ナノ秒: 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スクリプトSHOULD NOTはそれが使用しないどんな名前空間も指定します。 互換性、非名前空間意識する、パーサ、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.
取り扱い拡大の代替の方法として、示されました。 これは、スクリプト作者が、サーバがどの拡大をサポートするかをどうにか決心する必要でないスクリプトがサーバにアップロードされるのを許容するでしょう。 しかしながら、他の言語を開発するという経験(著しくSieve[22])はこれが過度の複雑さを言語に追加したということでした。 「拡大スイッチ」タグがそうすることができた、もちろん、それ自体、CPL拡張子では、定義されてください。
In the XML schema of CPL, we introduce three abstract elements, namely 'toplevelaction', 'switch', and 'action', which accordingly have the abstract type 'TopLevelActionType', 'SwitchType', and 'ActionType'. Any top-level action in a CPL extension MUST be defined as the substitutionGroup of the abstract 'toplevelaction' element, and have the type extended from the 'TopLevelActionType'. Any switch in a CPL extension MUST be defined as the substitutionGroup of the abstract 'switch' element, and have the type
CPLのXML図式では、私たちはそれに従って、抽象型'TopLevelActionType'、'SwitchType'、および'ActionType'を持っている3つの抽象的な要素、すなわち、'toplevelaction'、'スイッチ'、および'動作'を紹介します。 CPL拡張子におけるどんなトップレベル動作でも、抽象的な'toplevelaction'要素のsubstitutionGroupと定義されて、'TopLevelActionType'からタイプを広げなければなりません。 CPL拡張子におけるどんなスイッチにも、抽象的な'スイッチ'要素のsubstitutionGroupと定義されて、タイプがなければなりません。
Lennox, et al. Standards Track [Page 36] RFC 3880 CPL October 2004
レノックス、他 規格はCPL2004年10月にRFC3880を追跡します[36ページ]。
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'.
'SwitchType'から、広げられます。 CPL拡張子におけるどんな動作でも、抽象的な'動作'要素のsubstitutionGroupと定義されて、'ActionType'からタイプを広げなければなりません。
12. Examples
12. 例
12.1. Example: Call Redirect Unconditional
12.1. 例: 再直接で、無条件の状態で呼びます。
The script in Figure 19 is a simple script that redirects all calls to a single fixed location.
図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バージョン=、「=「UTF-8インチ?」をコード化する1インチ><cpl xmlns=「つぼ:ietf:params:xml:ナノ秒: cpl」xmlns: xsiは" http://www.w3.org/2001/XMLSchema-instance "xsiと等しいです: schemaLocationが「つぼ:ietf:params: xml:ナノ秒:cpl cpl.xsd「>の入って来る><位置のurl<=」一口: smith@phone.example.com 」と等しい、gt;、<再直接の/></位置の></入って来る></cplな>。
Figure 19: Example Script: Call Redirect Unconditional
図19: 例のスクリプト: 再直接で、無条件の状態で呼びます。
Lennox, et al. Standards Track [Page 37] RFC 3880 CPL October 2004
レノックス、他 規格はCPL2004年10月にRFC3880を追跡します[37ページ]。
12.2. Example: Call Forward Busy/No Answer
12.2. 例: どんな答えにも前方に忙しい/に電話をしないでください。
The script in Figure 20 illustrates some more complex behavior. We see an initial proxy attempt to one address, with further operations if that fails. We also see how several outputs take the same action subtree, through the use of subactions.
図20のスクリプトはそれ以上の複雑な振舞いを例証します。 それが失敗するなら、私たちは1つのアドレスへのさらなる操作による初期のプロキシ試みを見ます。 また、私たちは数個の出力が副動作の使用でどう同じ動作下位木を取るかを見ます。
<?xml version="1.0" encoding="UTF-8"?>
<cpl xmlns="urn:ietf:params:xml:ns:cpl"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="urn:ietf:params:xml:ns:cpl cpl.xsd ">
<subaction id="voicemail">
<location url="sip:jones@voicemail.example.com">
<proxy/>
</location>
</subaction>
<incoming>
<location url="sip:jones@jonespc.example.com">
<proxy timeout="8">
<busy>
<sub ref="voicemail"/>
</busy>
<noanswer>
<sub ref="voicemail"/>
</noanswer>
</proxy>
</location>
</incoming>
</cpl>
<?xmlバージョン=、「=「UTF-8インチ?」をコード化する1インチ><cpl xmlns=「つぼ:ietf:params:xml:ナノ秒: cpl」xmlns: xsiは" http://www.w3.org/2001/XMLSchema-instance "xsiと等しいです:; schemaLocationが「つぼ:ietf:params: xml:ナノ秒:cpl cpl.xsd「><副動作イド=」ボイスメール「><位置のurl=」一口: jones@voicemail.example.com 」と等しい、gt;、<プロキシ/></位置の></副動作の>の<の入って来る><位置のurlが「一口: jones@jonespc.example.com 」と等しい、gt; 「<プロキシタイムアウト=「8インチの><忙しい><潜水艦審判=」ボイスメール」/></忙しい>のnoanswer><潜水艦審判=「ボイスメール」/><</noanswer></プロキシ></位置の></入って来る></cpl>。
Figure 20: Example Script: Call Forward Busy/No Answer
図20: 例のスクリプト: どんな答えにも前方に忙しい/に電話をしないでください。
Lennox, et al. Standards Track [Page 38] RFC 3880 CPL October 2004
レノックス、他 規格はCPL2004年10月にRFC3880を追跡します[38ページ]。
12.3. Example: Call Forward: Redirect and Default
12.3. 例: 前方に電話をしてください: 再直接、デフォルトとしてください。
The script in Figure 21 illustrates further proxy behavior. The server initially tries to proxy to a single address. If this attempt is redirected, a new redirection is generated using the locations returned. In all other failure cases for the proxy node, a default operation -- forwarding to voicemail -- is performed.
図21のスクリプトはさらなるプロキシの振舞いを例証します。 サーバは初めは、ただ一つのアドレスへのプロキシに試みます。 この試みが向け直されるなら、位置が返した使用は新しいリダイレクションに生成されます。 プロキシノードのための他のすべての失敗事件では、デフォルト操作(ボイスメールへの推進)は実行されます。
<?xml version="1.0" encoding="UTF-8"?>
<cpl xmlns="urn:ietf:params:xml:ns:cpl"
xmlns:xsi="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バージョン=、「=「UTF-8インチ?」をコード化する1インチ><cpl xmlns=「つぼ:ietf:params:xml:ナノ秒: cpl」xmlns: xsiは" http://www.w3.org/2001/XMLSchema-instance "xsiと等しいです:; schemaLocationが「つぼ:ietf:params: xml:ナノ秒:cpl cpl.xsd「>の入って来る><位置のurl<=」一口: jones@jonespc.example.com 」と等しい、gt;、<><再直接の/>プロキシ><リダイレクション</リダイレクション><デフォルト><位置のurlが「一口: jones@voicemail.example.com 」と等しい、gt;、<プロキシ/></位置の></デフォルト></プロキシ></位置の></入って来る></cpl>。
Figure 21: Example Script: Call Forward: Redirect and Default
図21: 例のスクリプト: 前方に電話をしてください: 再直接、デフォルトとしてください。
Lennox, et al. Standards Track [Page 39] RFC 3880 CPL October 2004
レノックス、他 規格はCPL2004年10月にRFC3880を追跡します[39ページ]。
12.4. Example: Call Screening
12.4. 例: 呼び出し選別
The script in Figure 22 illustrates address switches and call rejection, in the form of a call screening script. Note also that because the address-switch lacks an "otherwise" clause, if the initial pattern does not match, the script does not define any operations. The server therefore proceeds with its default behavior, which would presumably be to contact the user.
図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バージョン=、「=「UTF-8インチ?」をコード化する1インチ><cpl xmlns=「つぼ:ietf:params:xml:ナノ秒: cpl」xmlns: xsiは" http://www.w3.org/2001/XMLSchema-instance "xsiと等しいです: schemaLocationは「つぼ:ietf:params: xml:ナノ秒:cpl cpl.xsd「>の<の入って来る><アドレススイッチ分野=」発生源」「私は匿名の電話を拒絶する」/></アドレス>アドレス</スイッチ></入って来る></cpl部分体=「「><アドレスは=です」というユーザの匿名の「><廃棄物状態=」廃棄物」理由=>と等しいです。
Figure 22: Example Script: Call Screening
図22: 例のスクリプト: 呼び出し選別
Lennox, et al. Standards Track [Page 40] RFC 3880 CPL October 2004
レノックス、他 規格はCPL2004年10月にRFC3880を追跡します[40ページ]。
12.5. Example: Priority and Language Routing
12.5. 例: 優先権と言語ルート設定
The script in Figure 23 illustrates service selection based on a call's priority value and language settings. If the call request had a priority of "urgent" or higher, the default script behavior is performed. Otherwise, the language field is checked for the language "es" (Spanish). If it is present, the call is proxied to a Spanish- speaking operator; other calls are proxied to an English-speaking operator.
図23のスクリプトは呼び出しの優先順位の値と言語設定に基づくサービス選択を例証します。 発呼要求に「緊急である」か、より高いことの優先があったなら、デフォルトスクリプトの振舞いは実行されます。 さもなければ、言語分野は言語"es"(スペインの)がないかどうかチェックされます。 それが存在しているなら、呼び出しはオペレータを話しながら、スペイン人にproxiedされます。 他の呼び出しはイギリスの話しているオペレータにproxiedされます。
<?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バージョン=、「=「UTF-8インチ?」をコード化する1インチ><cpl xmlns=「つぼ:ietf:params:xml:ナノ秒: cpl」xmlns: xsiは" http://www.w3.org/2001/XMLSchema-instance "xsiと等しいです:; schemaLocationが等しい、「つぼ:ietf:params:xml:ナノ秒: cpl cpl.xsd、「>の<の入って来る><が、よりすばらしい状態で><優先権を優先権で切り換える、等しさ、」、緊急である、」 /><、そうでなければ、><言語スイッチ><言語マッチ=「es「><位置のurl=」一口: spanish@operator.example.com 」、gt;、<プロキシ/> </位置の></言語><、さもなければ、><位置のurlが「一口: english@operator.example.com 」と等しい、gt;、<プロキシ/></位置></そうでなければ、></言語-スイッチ></そうでなければ、>優先権</スイッチ></入って来る></cplな>。
Figure 23: Example Script: Priority and Language Routing
図23: 例のスクリプト: 優先権と言語ルート設定
Lennox, et al. Standards Track [Page 41] RFC 3880 CPL October 2004
レノックス、他 規格はCPL2004年10月にRFC3880を追跡します[41ページ]。
12.6. Example: Outgoing Call Screening
12.6. 例: 発信電話選別
The script in Figure 24 illustrates a script filtering outgoing calls, in the form of a script which prevent 1-900 (premium) calls from being placed. This script also illustrates subdomain matching.
The script in Figure 24 illustrates a script filtering outgoing calls, in the form of a script which prevent 1-900 (premium) calls from being placed. This script also illustrates subdomain matching.
<?xml version="1.0" encoding="UTF-8"?>
<cpl xmlns="urn:ietf:params:xml:ns:cpl"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="urn:ietf:params:xml:ns:cpl cpl.xsd ">
<outgoing>
<address-switch field="original-destination" subfield="tel">
<address subdomain-of="1900">
<reject status="reject"
reason="Not allowed to make 1-900 calls."/>
</address>
</address-switch>
</outgoing>
</cpl>
<?xml version="1.0" encoding="UTF-8"?> <cpl xmlns="urn:ietf:params:xml:ns:cpl" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="urn:ietf:params:xml:ns:cpl cpl.xsd "> <outgoing> <address-switch field="original-destination" subfield="tel"> <address subdomain-of="1900"> <reject status="reject" reason="Not allowed to make 1-900 calls."/> </address> </address-switch> </outgoing> </cpl>
Figure 24: Example Script: Outgoing Call Screening
Figure 24: Example Script: Outgoing Call Screening
Lennox, et al. Standards Track [Page 42] RFC 3880 CPL October 2004
Lennox, et al. Standards Track [Page 42] RFC 3880 CPL October 2004
12.7. Example: Time-of-day Routing
12.7. Example: Time-of-day Routing
Figure 25 illustrates time-based conditions and timezones.
Figure 25 illustrates time-based conditions and timezones.
<?xml version="1.0" encoding="UTF-8"?>
<cpl xmlns="urn:ietf:params:xml:ns:cpl"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="urn:ietf:params:xml:ns:cpl cpl.xsd ">
<incoming>
<time-switch tzid="America/New_York"
tzurl="http://zones.example.com/tz/America/New_York">
<time dtstart="20000703T090000" duration="PT8H" freq="weekly"
byday="MO,TU,WE,TH,FR">
<lookup source="registration">
<success>
<proxy/>
</success>
</lookup>
</time>
<otherwise>
<location url="sip:jones@voicemail.example.com">
<proxy/>
</location>
</otherwise>
</time-switch>
</incoming>
</cpl>
<?xml version="1.0" encoding="UTF-8"?> <cpl xmlns="urn:ietf:params:xml:ns:cpl" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="urn:ietf:params:xml:ns:cpl cpl.xsd "> <incoming> <time-switch tzid="America/New_York" tzurl="http://zones.example.com/tz/America/New_York"> <time dtstart="20000703T090000" duration="PT8H" freq="weekly" byday="MO,TU,WE,TH,FR"> <lookup source="registration"> <success> <proxy/> </success> </lookup> </time> <otherwise> <location url="sip:jones@voicemail.example.com"> <proxy/> </location> </otherwise> </time-switch> </incoming> </cpl>
Figure 25: Example Script: Time-of-day Routing
Figure 25: Example Script: Time-of-day Routing
Lennox, et al. Standards Track [Page 43] RFC 3880 CPL October 2004
Lennox, et al. Standards Track [Page 43] RFC 3880 CPL October 2004
12.8. Example: Location Filtering
12.8. Example: Location Filtering
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.
Figure 26 illustrates filtering operations on the location set. In this example, we assume that version 0.9beta2 of the "Inadequate Software SIP User Agent" mis-implements some features, and so we must work around its problems. We know that it cannot talk successfully to one particular mobile device we may have registered, so we remove that location from the location set. Once this operation has been completed, call setup is allowed to proceed normally.
<?xml version="1.0" encoding="UTF-8"?>
<cpl xmlns="urn:ietf:params:xml:ns:cpl"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="urn:ietf:params:xml:ns:cpl cpl.xsd ">
<incoming>
<string-switch field="user-agent">
<string is="Inadequate Software SIP User Agent/0.9beta2">
<lookup source="registration">
<success>
<remove-location location="sip:me@mobile.provider.net">
<proxy/>
</remove-location>
</success>
</lookup>
</string>
</string-switch>
</incoming>
</cpl>
<?xml version="1.0" encoding="UTF-8"?> <cpl xmlns="urn:ietf:params:xml:ns:cpl" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="urn:ietf:params:xml:ns:cpl cpl.xsd "> <incoming> <string-switch field="user-agent"> <string is="Inadequate Software SIP User Agent/0.9beta2"> <lookup source="registration"> <success> <remove-location location="sip:me@mobile.provider.net"> <proxy/> </remove-location> </success> </lookup> </string> </string-switch> </incoming> </cpl>
Figure 26: Example Script: Location Filtering
Figure 26: Example Script: Location Filtering
Lennox, et al. Standards Track [Page 44] RFC 3880 CPL October 2004
Lennox, et al. Standards Track [Page 44] RFC 3880 CPL October 2004
12.9. Example: Non-signalling Operations
12.9. Example: Non-signalling Operations
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.
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.
<?xml version="1.0" encoding="UTF-8"?>
<cpl xmlns="urn:ietf:params:xml:ns:cpl"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="urn:ietf:params:xml:ns:cpl cpl.xsd ">
<incoming>
<lookup
source="http://www.example.com/cgi-bin/locate.cgi?user=mary"
timeout="8">
<success>
<proxy/>
</success>
<failure>
<mail url="mailto:mary@example.com?subject=Lookup%20failed"/>
</failure>
</lookup>
</incoming>
</cpl>
<?xml version="1.0" encoding="UTF-8"?> <cpl xmlns="urn:ietf:params:xml:ns:cpl" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="urn:ietf:params:xml:ns:cpl cpl.xsd "> <incoming> <lookup source="http://www.example.com/cgi-bin/locate.cgi?user=mary" timeout="8"> <success> <proxy/> </success> <failure> <mail url="mailto:mary@example.com?subject=Lookup%20failed"/> </failure> </lookup> </incoming> </cpl>
Figure 27: Example Script: Non-signalling Operations
Figure 27: Example Script: Non-signalling Operations
Lennox, et al. Standards Track [Page 45] RFC 3880 CPL October 2004
Lennox, et al. Standards Track [Page 45] RFC 3880 CPL October 2004
12.10. Example: Hypothetical Extensions
12.10. Example: Hypothetical Extensions
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".
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".
<?xml version="1.0" encoding="UTF-8"?>
<xs:schema targetNamespace="http://www.example.com/distinctive-ring"
xmlns="http://www.example.com/distinctive-ring"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns:CPL="urn:ietf:params:xml:ns:cpl"
elementFormDefault="qualified"
attributeFormDefault="unqualified">
<xs:import namespace="urn:ietf:params:xml:ns:cpl"
schemaLocation="cpl.xsd"/>
<xs:complexType name="DRingAction">
<xs:complexContent>
<xs:extension base="CPL:ActionType">
<xs:attribute name="ringstyle" type="xs:string"
use="optional"/>
</xs:extension>
</xs:complexContent>
</xs:complexType>
<xs:element name="ring" type="DRingAction"
substitutionGroup="CPL:action"/>
</xs:schema>
<?xml version="1.0" encoding="UTF-8"?> <xs:schema targetNamespace="http://www.example.com/distinctive-ring" xmlns="http://www.example.com/distinctive-ring" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:CPL="urn:ietf:params:xml:ns:cpl" elementFormDefault="qualified" attributeFormDefault="unqualified"> <xs:import namespace="urn:ietf:params:xml:ns:cpl" schemaLocation="cpl.xsd"/> <xs:complexType name="DRingAction"> <xs:complexContent> <xs:extension base="CPL:ActionType"> <xs:attribute name="ringstyle" type="xs:string" use="optional"/> </xs:extension> </xs:complexContent> </xs:complexType> <xs:element name="ring" type="DRingAction" substitutionGroup="CPL:action"/> </xs:schema>
<?xml version="1.0" encoding="UTF-8"?>
<cpl xmlns="urn:ietf:params:xml:ns:cpl"
xmlns:dr="http://www.example.com/distinctive-ring"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="urn:ietf:params:xml:ns:cpl cpl.xsd
http://www.example.com/distinctive-ring distinctive-ring.xsd">
<incoming>
<address-switch field="origin">
<address is="sip:boss@example.com">
<dr:ring ringstyle="warble"/>
</address>
</address-switch>
</incoming>
</cpl>
<?xml version="1.0" encoding="UTF-8"?> <cpl xmlns="urn:ietf:params:xml:ns:cpl" xmlns:dr="http://www.example.com/distinctive-ring" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="urn:ietf:params:xml:ns:cpl cpl.xsd http://www.example.com/distinctive-ring distinctive-ring.xsd"> <incoming> <address-switch field="origin"> <address is="sip:boss@example.com"> <dr:ring ringstyle="warble"/> </address> </address-switch> </incoming> </cpl>
Figure 28: Example Schema and Script: Hypothetical
Distinctive-Ringing Extension
Figure 28: Example Schema and Script: Hypothetical Distinctive-Ringing Extension
Lennox, et al. Standards Track [Page 46] RFC 3880 CPL October 2004
Lennox, et al. Standards Track [Page 46] RFC 3880 CPL October 2004
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.
The example in Figure 29 implements a hypothetical new attribute for address switches, to allow regular-expression matches. It defines a new attribute "regex" for the standard "address" node.
<?xml version="1.0" encoding="UTF-8"?>
<cpl xmlns="urn:ietf:params:xml:ns:cpl"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="urn:ietf:params:xml:ns:cpl cpl.xsd ">
<incoming>
<address-switch field="origin" subfield="user"
xmlns:re="http://www.example.com/regex">
<address re:regex="(.*.smith|.*.jones)">
<reject status="reject"
reason="I don't want to talk to Smiths or Joneses"/>
</address>
</address-switch>
</incoming>
</cpl>
<?xml version="1.0" encoding="UTF-8"?> <cpl xmlns="urn:ietf:params:xml:ns:cpl" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="urn:ietf:params:xml:ns:cpl cpl.xsd "> <incoming> <address-switch field="origin" subfield="user" xmlns:re="http://www.example.com/regex"> <address re:regex="(.*.smith|.*.jones)"> <reject status="reject" reason="I don't want to talk to Smiths or Joneses"/> </address> </address-switch> </incoming> </cpl>
Figure 29: Example Script: Hypothetical Regular-Expression Extension
Figure 29: Example Script: Hypothetical Regular-Expression Extension
Lennox, et al. Standards Track [Page 47] RFC 3880 CPL October 2004
Lennox, et al. Standards Track [Page 47] RFC 3880 CPL October 2004
12.11. Example: A Complex Example
12.11. Example: A Complex Example
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.
Finally, Figure 30 is a complex example which shows the sort of sophisticated behavior that can be achieved by combining CPL nodes. In this case, the user attempts to have his calls reach his desk; if he does not answer within a small amount of time, calls from his boss are forwarded to his mobile phone, and all other calls are directed to voicemail. If the call setup failed, no operation is specified, so the server's default behavior is performed.
<?xml version="1.0" encoding="UTF-8"?>
<cpl xmlns="urn:ietf:params:xml:ns:cpl"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="urn:ietf:params:xml:ns:cpl cpl.xsd ">
<subaction id="voicemail">
<location url="sip:jones@voicemail.example.com">
<redirect />
</location>
</subaction>
<incoming>
<location url="sip:jones@phone.example.com">
<proxy timeout="8">
<busy>
<sub ref="voicemail" />
</busy>
<noanswer>
<address-switch field="origin">
<address is="sip:boss@example.com">
<location url="tel:+19175551212">
<proxy />
</location>
</address>
<otherwise>
<sub ref="voicemail" />
</otherwise>
</address-switch>
</noanswer>
</proxy>
</location>
</incoming>
</cpl>
<?xml version="1.0" encoding="UTF-8"?> <cpl xmlns="urn:ietf:params:xml:ns:cpl" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="urn:ietf:params:xml:ns:cpl cpl.xsd "> <subaction id="voicemail"> <location url="sip:jones@voicemail.example.com"> <redirect /> </location> </subaction> <incoming> <location url="sip:jones@phone.example.com"> <proxy timeout="8"> <busy> <sub ref="voicemail" /> </busy> <noanswer> <address-switch field="origin"> <address is="sip:boss@example.com"> <location url="tel:+19175551212"> <proxy /> </location> </address> <otherwise> <sub ref="voicemail" /> </otherwise> </address-switch> </noanswer> </proxy> </location> </incoming> </cpl>
Figure 30: Example Script: A Complex Example
Figure 30: Example Script: A Complex Example
Lennox, et al. Standards Track [Page 48] RFC 3880 CPL October 2004
Lennox, et al. Standards Track [Page 48] RFC 3880 CPL October 2004
13. Security Considerations
13. Security Considerations
CPL is designed to allow services to be specified in a manner which prevents potentially hostile or mis-configured scripts from launching security attacks, including denial-of-service attacks. Because script runtime is strictly bounded by acyclicity, and because the number of possible script operations are strictly limited, scripts should not be able to inflict damage upon a CPL server.
CPL is designed to allow services to be specified in a manner which prevents potentially hostile or mis-configured scripts from launching security attacks, including denial-of-service attacks. Because script runtime is strictly bounded by acyclicity, and because the number of possible script operations are strictly limited, scripts should not be able to inflict damage upon a CPL server.
Because scripts can direct users' telephone calls, the method by which scripts are transmitted from a client to a server MUST be strongly authenticated. Such a method is not specified in this document.
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.
Script servers SHOULD allow server administrators to control the details of what CPL operations are permitted.
14. IANA Considerations
14. IANA Considerations
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].
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].
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.
The XML namespace urn:ietf:params:xml:ns:cpl will only refer to the version of CPL in this document and will not change. Any CPL enhancements MUST be made by extensions and MUST have different namespaces.
14.1. URN Sub-Namespace Registration for urn:ietf:params:xml:ns:cpl
14.1. URN Sub-Namespace Registration for urn:ietf:params:xml:ns:cpl
URI: urn:ietf:params:xml:ns:cpl
URI: urn:ietf:params:xml:ns:cpl
Registrant Contact: Jonathan Lennox <lennox@cs.columbia.edu>
Xiaotao Wu <xiaotaow@cs.columbia.edu>
Henning Schulzrinne <hgs@cs.columbia.edu>
Registrant Contact: Jonathan Lennox <lennox@cs.columbia.edu> Xiaotao Wu <xiaotaow@cs.columbia.edu> Henning Schulzrinne <hgs@cs.columbia.edu>
XML:
XML:
BEGIN
<?xml version="1.0"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML Basic 1.0//EN"
"http://www.w3.org/TR/xhtml-basic/xhtml-basic10.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta http-equiv="content-type"
content="text/html;charset=iso-8859-1"/>
<title>Call Processing Language Namespace</title>
</head>
<body>
BEGIN <?xml version="1.0"?> <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML Basic 1.0//EN" "http://www.w3.org/TR/xhtml-basic/xhtml-basic10.dtd"> <html xmlns="http://www.w3.org/1999/xhtml"> <head> <meta http-equiv="content-type" content="text/html;charset=iso-8859-1"/> <title>Call Processing Language Namespace</title> </head> <body>
Lennox, et al. Standards Track [Page 49] RFC 3880 CPL October 2004
Lennox, et al. Standards Track [Page 49] RFC 3880 CPL October 2004
<h1>Namespace for Call Processing Language</h1>
<h2>urn:ietf:params:xml:ns:cpl</h2>
<p><a href="ftp://ftp.rfc-editor.org/in-notes/rfc3880.txt">
RFC3880</a>.</p>
</body>
</html>
END
<h1>Namespace for Call Processing Language</h1> <h2>urn:ietf:params:xml:ns:cpl</h2> <p><a href="ftp://ftp.rfc-editor.org/in-notes/rfc3880.txt"> RFC3880</a>.</p> </body> </html> END
14.2. Schema registration
14.2. Schema registration
This specification registers XML Schema for CPL, as per the guidelines in [14].
This specification registers XML Schema for CPL, as per the guidelines in [14].
URI: urn:ietf:params:xml:schema:cpl
URI: urn:ietf:params:xml:schema:cpl
Registrant contact:
Jonathan Lennox <lennox@cs.columbia.edu>
Xiaotao Wu <xiaotaow@cs.columbia.edu>
Henning Schulzrinne <hgs@cs.columbia.edu>
Registrant contact: Jonathan Lennox <lennox@cs.columbia.edu> Xiaotao Wu <xiaotaow@cs.columbia.edu> Henning Schulzrinne <hgs@cs.columbia.edu>
XML: The XML can be found in Appendix C.
XML: The XML can be found in Appendix C.
14.3. MIME Registration
14.3. MIME Registration
As an XML type, CPL's MIME registration conforms with "XML Media Types," RFC 3023 [15].
As an XML type, CPL's MIME registration conforms with "XML Media Types," RFC 3023 [15].
MIME media type name: application
MIME media type name: application
MIME subtype name: cpl+xml
MIME subtype name: cpl+xml
Mandatory parameters: none
Mandatory parameters: none
Optional parameters: charset
As for application/xml in RFC 3023.
Optional parameters: charset As for application/xml in RFC 3023.
Encoding considerations: As for application/xml in RFC 3023.
Encoding considerations: As for application/xml in RFC 3023.
Security considerations: See Section 13, and Section 10 of RFC
3023.
Security considerations: See Section 13, and Section 10 of RFC 3023.
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.
Interoperability considerations: Different CPL servers may use incompatible address types. However, all potential interoperability issues should be resolvable at the time a script is uploaded; there should be no interoperability issues which cannot be detected until runtime.
Published specification: This document.
Published specification: This document.
Lennox, et al. Standards Track [Page 50] RFC 3880 CPL October 2004
Lennox, et al. Standards Track [Page 50] RFC 3880 CPL October 2004
Applications which use this media type: SIP proxy servers and
other telephony servers, and client software to control
their behavior.
Applications which use this media type: SIP proxy servers and other telephony servers, and client software to control their behavior.
Additional information:
Additional information:
Magic number: None
Magic number: None
File extension: .cpl or .xml
File extension: .cpl or .xml
Macintosh file type code: "TEXT"
Macintosh file type code: "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>
Person and e-mail address for further information: Jonathan Lennox <lennox@cs.columbia.edu> Xiaotao Wu <xiaotaow@cs.columbia.edu> Henning Schulzrinne <hgs@cs.columbia.edu>
Intended usage: COMMON
Intended usage: COMMON
Author/Change Controller: The IETF.
Author/Change Controller: The IETF.
15. Acknowledgments
15. Acknowledgments
This document was reviewed and commented upon by the IETF IP Telephony Working Group. We specifically acknowledge the following people for their help:
This document was reviewed and commented upon by the IETF IP Telephony Working Group. We specifically acknowledge the following people for their help:
The outgoing call screening script was written by Kenny Hom.
The outgoing call screening script was written by Kenny Hom.
Paul E. Jones contributed greatly to the mappings of H.323 addresses.
Paul E. Jones contributed greatly to the mappings of H.323 addresses.
The text of the time-switch section was taken (lightly modified) from RFC 2445 [8], by Frank Dawson and Derik Stenerson.
The text of the time-switch section was taken (lightly modified) from RFC 2445 [8], by Frank Dawson and Derik Stenerson.
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.
We drew a good deal of inspiration, notably the language's lack of Turing-completeness and the syntax of string matching, from the specification of Sieve [22], a language for user filtering of electronic mail messages.
Thomas F. La Porta and Jonathan Rosenberg had many useful discussions, contributions, and suggestions.
Thomas F. La Porta and Jonathan Rosenberg had many useful discussions, contributions, and suggestions.
Richard Gumpertz performed a very useful last-minute technical and editorial review of the specification.
Richard Gumpertz performed a very useful last-minute technical and editorial review of the specification.
Lennox, et al. Standards Track [Page 51] RFC 3880 CPL October 2004
Lennox, et al. Standards Track [Page 51] RFC 3880 CPL October 2004
A. An Algorithm for Resolving Time Switches
A. An Algorithm for Resolving Time Switches
The following algorithm determines whether a given instant falls within a repetition of a "time-switch" recurrence. If the pre- processing described in Section 4.4.1 has been done, it operates in constant time. Open-source Java code implementing this algorithm is available at http://www.cs.columbia.edu/~lennox/Cal-Code/ on the world wide web.
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.
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.
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.
1. Compute the time of the call, in the timezone of the time
switch.
1. Compute the time of the call, in the timezone of the time switch.
2. If the call time is earlier than "dtstart", fail NOMATCH.
2. If the call time is earlier than "dtstart", fail NOMATCH.
3. If the call time is less than "duration" after dtstart, succeed
MATCH.
3. If the call time is less than "duration" after dtstart, succeed MATCH.
4. Determine the smallest unit specified in a "byxxx" rule or by
the "freq." Call this the Minimum Unit. Determine the
previous instant (before or equal to the call time) when all
the time units smaller than the minimum unit are the same as
those of "dtstart." If the minimum unit is a second, this time
is the same as the instant. If the minimum unit is a minute or
an hour, the minutes or the minutes and hours, respectively,
must be the same as "dtstart". For all other minimum units,
the time-of-day must be the same as "dtstart." If the minimum
unit is a week, the day-of-the-week must be the same as
"dtstart." If the minimum unit is a month, the day-of-the-
month must be the same as "dtstart." If the minimum unit is a
year, the month and day-of-month must both be the same as
"dtstart." (Note that this means it may be necessary to roll
back more than one minimum unit -- if the minimum unit is a
month, then some months do not have a 31st (or 30th or 29th)
day; if the minimum unit is a year, then some years do not have
a February 29th. In the Gregorian calendar, it is never
necessary to roll back more than two months if the minimum unit
is a month, or eight years if the minimum unit is a year.
Between 1904 and 2096, it is never necessary to roll back more
than four years -- the eight-year rollback can only occur when
the Gregorian calendar "skips" a leap year.
4. 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.
Call this instant the Candidate Start Time.
Call this instant the Candidate Start Time.
Lennox, et al. Standards Track [Page 52] RFC 3880 CPL October 2004
Lennox, et al. Standards Track [Page 52] RFC 3880 CPL October 2004
5. If the time between the candidate start time and the call time
is more than the duration, fail NOMATCH.
5. If the time between the candidate start time and the call time is more than the duration, fail NOMATCH.
6. If the candidate start time is later than the "until" parameter
of the recurrence (or the virtual "until" computed off-line
from "count"), fail NOMATCH.
6. If the candidate start time is later than the "until" parameter of the recurrence (or the virtual "until" computed off-line from "count"), fail NOMATCH.
7. Call the unit of the "freq" parameter of the recurrence the
Frequency Unit. Determine the frequency unit enclosing the
Candidate Start Time, and that enclosing "dtstart". Calculate
the number of frequency units that have passed between these
two times. If this is not a multiple of the "interval"
parameter, fail NOMATCH.
7. Call the unit of the "freq" parameter of the recurrence the Frequency Unit. Determine the frequency unit enclosing the Candidate Start Time, and that enclosing "dtstart". Calculate the number of frequency units that have passed between these two times. If this is not a multiple of the "interval" parameter, fail NOMATCH.
8. For every "byxxx" rule, confirm that the candidate start time
matches one of the options specified by that "byxxx" rule. If
so, succeed MATCH.
8. For every "byxxx" rule, confirm that the candidate start time matches one of the options specified by that "byxxx" rule. If so, succeed MATCH.
9. Calculate a previous candidate start time. Repeat until the
difference between the candidate start time and the call time
is more than the duration. If no candidate start time has been
validated, fail NOMATCH.
9. Calculate a previous candidate start time. Repeat until the difference between the candidate start time and the call time is more than the duration. If no candidate start time has been validated, fail NOMATCH.
B. Suggested Usage of CPL with H.323
B. Suggested Usage of CPL with H.323
This appendix gives a suggested usage of CPL with H.323 [16]. Study Group 16 of the ITU, which developed H.323, is proposing to work on official CPL mappings for that protocol. This section is therefore not normative.
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.
B.1. Usage of "address-switch" with H.323
B.1. Usage of "address-switch" with 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.
Address switches are specified in Section 4.1. This section specifies the mapping between H.323 messages and the fields and subfields of address-switches.
For H.323, the "origin" address corresponds to the alias addresses in the "sourceAddress" field of the "Setup-UUIE" user-user information element, and to the Q.931 [23] information element "Calling party number." If both fields are present, or if multiple alias addresses for "sourceAddress" are present, which one has priority is a matter of local server policy; the server SHOULD use the same resolution as it would use for routing decisions in this case. Similarly, the "destination" address corresponds to the alias addresses of the "destinationAddress" field, and to the Q.931 information element "Called party number."
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."
Lennox, et al. Standards Track [Page 53] RFC 3880 CPL October 2004
Lennox, et al. Standards Track [Page 53] RFC 3880 CPL October 2004
The "original-destination" address corresponds to the "Redirecting number" Q.931 information element, if it is present; otherwise it is the same as the "destination" address.
The "original-destination" address corresponds to the "Redirecting number" Q.931 information element, if it is present; otherwise it is the same as the "destination" address.
The mapping of H.323 addresses into subfields depends on the type of the alias address. An additional subfield type, "alias-type", is defined for H.323 servers, corresponding to the type of the address. Possible values are "dialedDigits", "h323-ID", "url-ID", "transportID", "email-ID", "partyNumber", "mobileUIM", and "Q.931IE". If future versions of the H.323 specification define additional types of alias addresses, those names MAY also be used.
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.
In versions of H.323 prior to version 4, "dialedDigits" was known as "e164". The two names SHOULD be treated as synonyms.
In versions of H.323 prior to version 4, "dialedDigits" was known as "e164". The two names SHOULD be treated as synonyms.
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.
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.
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.
An H.323-aware CPL server SHOULD map the address subfields from the primary alias used for routing. It MAY also map subfields from other aliases, if subfields in the primary address are not present.
The following mappings are used for H.323 alias types:
The following mappings are used for H.323 alias types:
dialedDigits, partyNumber, mobileUIM, and Q.931IE: the "tel" and
"user" subfields are the string of digits, as is the
"entire-address" form. The "host" and "port" subfields are
not present.
dialedDigits, partyNumber, mobileUIM, 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.
url-ID: the same mappings are used as for SIP, in Section 4.1.1.
url-ID: the same mappings are used as for SIP, in Section 4.1.1.
h323-ID: the "user" field is the string of characters, as is the
"entire-address" form. All other subfields are not present.
h323-ID: the "user" field is the string of characters, as is the "entire-address" form. All other subfields are not present.
email-ID: the "user" and "host" subfields are set to the
corresponding parts of the e-mail address. The "port" and
"tel" subfields are not present. The "entire-address" form
corresponds to the entire e-mail address.
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.
transportID: if the TransportAddress is of type "ipAddress,"
"ipSourceRoute," or "ip6Address," the "host" subfield is set
to the "ip" element of the sequence, translated into the
standard IPv4 or IPv6 textual representation, and the "port"
subfield is set to the "port" element of the sequence
represented in decimal. The "tel" and "user" fields are not
present. The "entire-address" form is not defined. The
transportID: 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
Lennox, et al. Standards Track [Page 54] RFC 3880 CPL October 2004
Lennox, et al. Standards Track [Page 54] RFC 3880 CPL October 2004
representation and mapping of transport addresses is not
defined for non-IP addresses.
representation and mapping of transport addresses is not defined for non-IP addresses.
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] 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.
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.
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.
This mapping MAY be used both for h323 URIs in an h323 "url-ID" address alias, and for h323 URIs in SIP messages.
This mapping MAY be used both for h323 URIs in an h323 "url-ID" address alias, and for h323 URIs in SIP messages.
B.2. Usage of "string-switch" with H.323
B.2. Usage of "string-switch" with 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.
For H.323, the "string-switch" node (see Section 4.2) is used as follows. The field "display" corresponds to the Q.931 information element of the same name, copied verbatim. The fields "subject", "organization", and "user-agent" are not used and are never present.
The "display" IE is conventionally used for Caller-ID purposes, so
arguably it should be mapped to the "display" subfield of an
"address-match" with the field "originator". However, since a) it
is a message-level information element, not an address-level one,
and b) the Q.931 specification [23] says only that "[t]he purpose
of the Display information element is to supply display
information that may be displayed by the user," it seems to be
more appropriate to allow it to be matched in a "string-switch"
instead.
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.
B.3. Usage of "language-switch" with H.323
B.3. Usage of "language-switch" with 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.
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.
B.4. Usage of "priority-switch" with H.323
B.4. Usage of "priority-switch" with H.323
All H.323 messages are considered to have priority "normal" for the purpose of a priority switch (see Section 4.5).
All H.323 messages are considered to have priority "normal" for the purpose of a priority switch (see Section 4.5).
Lennox, et al. Standards Track [Page 55] RFC 3880 CPL October 2004
Lennox, et al. Standards Track [Page 55] RFC 3880 CPL October 2004
B.5. Usage of "location" with H.323
B.5. Usage of "location" with 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.
Locations in explicit location nodes (Section 5.1) are specified as URLs. Therefore, all locations added in this manner are interpreted as being of alias type "url-ID" in H.323.
Specifications of other H.323 address alias types will require a CPL extension (see Section 11).
Specifications of other H.323 address alias types will require a CPL extension (see Section 11).
B.6. Usage of "lookup" with H.323
B.6. Usage of "lookup" with H.323
For location lookup nodes (Section 5.2), the "registration" lookup source corresponds to the locations registered with the server using "RAS" messages.
For location lookup nodes (Section 5.2), the "registration" lookup source corresponds to the locations registered with the server using "RAS" messages.
B.7. Usage of "remove-location" with H.323
B.7. Usage of "remove-location" with 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.
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.
C. The XML Schema for CPL
C. The XML Schema for CPL
This section includes a full XML Schema describing the XML syntax of CPL. Every script submitted to a CPL server SHOULD comply with this XML Schema. When parsing scripts comply with the CPL DTD in earlier documents, the DOCTYPE lines in the scripts should be ignored. Note that compliance with this schema is not a sufficient condition for correctness of a CPL script, as many of the conditions described in this specification are not expressible in schema syntax. Figure 31 shows the structure of the schema. 'incoming' and 'outgoing' are defined as the substitutionGroup of the 'toplevelaction'. All the switches are defined as the substitutionGroup of the 'switch' element. All the actions are defined as the substitutionGroup of the 'action' element.
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.
Lennox, et al. Standards Track [Page 56] RFC 3880 CPL October 2004
Lennox, et al. Standards Track [Page 56] RFC 3880 CPL October 2004
+---------+ +------+ +--address
+-+ancillary| |switch|** +--------------+ | +-not-present
| +---------+ +---+--+ **|address-switch+-+-+-address
| | * +--------------+ +--otherwise
| +---------+ +----+ | * +--language
+-+subaction+-+Node| | * +---------------+ | +-not-present
| +---------+ +----+ | **|language-switch|-+-+-language
| | * +---------------+ +--otherwise
| | * +--priority
| | * +---------------+ | +-not-present
| | **|priority-switch|-+-+-priority
| | * +---------------+ +--otherwise
| | * +--string
cpl-+ | * +-------------+ | +-not-present
| | **|string-switch|-+ +-string
| | * +-------------+ +--otherwise
| | * +--time
| +--------------+ +-+--+ * +-----------+ | +-not-present
+-+toplevelaction+-+Node| *|time-switch|-+-+-time
+-----*--------+ +-+--+ +-----------+ +--otherwise
* | +--------+ +----+
* | **|location+-|Node|
* | +--------+ * +--------+ +----+
* +--------+ |-+modifier|** +------+ +-success-Node
**|incoming| | +--------+ *-|lookup+-+-notfound-Node
* +--------+ | * +------+ +-failure-Node
* | +---+ * +---------------+ +----+
* +--------+ +-+Sub+-sub **|remove-location+-+Node|
*|outgoing| | +---+ +---------------+ +----+
+--------+ | +---+
| **|log+-Node
| * +---+
| * +----+
| +------+ **|mail+-Node
+-+action|** +----+ +-busy-Node
---- contains +------+ * +-----+ |
**|proxy+----+-noanswer-Node
**** substitutes * +-----+ |
* +--------+ +-failure-Node
**|redirect| |
* +--------+ +-redirection-Node
* +------+ |
*|reject| +-default-Node
+------+
+---------+ +------+ +--address +-+ancillary| |switch|** +--------------+ | +-not-present | +---------+ +---+--+ **|address-switch+-+-+-address | | * +--------------+ +--otherwise | +---------+ +----+ | * +--language +-+subaction+-+Node| | * +---------------+ | +-not-present | +---------+ +----+ | **|language-switch|-+-+-language | | * +---------------+ +--otherwise | | * +--priority | | * +---------------+ | +-not-present | | **|priority-switch|-+-+-priority | | * +---------------+ +--otherwise | | * +--string cpl-+ | * +-------------+ | +-not-present | | **|string-switch|-+ +-string | | * +-------------+ +--otherwise | | * +--time | +--------------+ +-+--+ * +-----------+ | +-not-present +-+toplevelaction+-+Node| *|time-switch|-+-+-time +-----*--------+ +-+--+ +-----------+ +--otherwise * | +--------+ +----+ * | **|location+-|Node| * | +--------+ * +--------+ +----+ * +--------+ |-+modifier|** +------+ +-success-Node **|incoming| | +--------+ *-|lookup+-+-notfound-Node * +--------+ | * +------+ +-failure-Node * | +---+ * +---------------+ +----+ * +--------+ +-+Sub+-sub **|remove-location+-+Node| *|outgoing| | +---+ +---------------+ +----+ +--------+ | +---+ | **|log+-Node | * +---+ | * +----+ | +------+ **|mail+-Node +-+action|** +----+ +-busy-Node ---- contains +------+ * +-----+ | **|proxy+----+-noanswer-Node **** substitutes * +-----+ | * +--------+ +-failure-Node **|redirect| | * +--------+ +-redirection-Node * +------+ | *|reject| +-default-Node +------+
Figure 31: The structure of the XML schema for CPL
Figure 31: The structure of the XML schema for CPL
Lennox, et al. Standards Track [Page 57] RFC 3880 CPL October 2004
Lennox, et al. Standards Track [Page 57] RFC 3880 CPL October 2004
BEGIN
<?xml version="1.0" encoding="UTF-8"?>
<xs:schema targetNamespace="urn:ietf:params:xml:ns:cpl"
xmlns="urn:ietf:params:xml:ns:cpl"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
elementFormDefault="qualified"
attributeFormDefault="unqualified">
<xs:complexType name="TopLevelActionType" abstract="true">
<xs:group ref="Node"/>
</xs:complexType>
<xs:element name="toplevelaction" type="TopLevelActionType"/>
<xs:complexType name="ActionType" abstract="true"/>
<xs:element name="action" type="ActionType"/>
<xs:complexType name="SwitchType" abstract="true"/>
<xs:element name="switch" type="SwitchType"/>
<xs:complexType name="ModifierType" abstract="true"/>
<xs:element name="modifier" type="ModifierType"/>
<xs:element name="location" type="LocationType"
substitutionGroup="modifier"/>
<xs:element name="lookup" type="LookupType"
substitutionGroup="modifier"/>
<xs:element name="remove-location" type="RemoveLocationType"
substitutionGroup="modifier"/>
<xs:element name="sub" type="SubAction"/>
<xs:group name="Node">
<xs:choice>
<xs:element ref="switch" minOccurs="0" maxOccurs="1"/>
<xs:element ref="modifier" minOccurs="0" maxOccurs="1"/>
<xs:element ref="sub" minOccurs="0" maxOccurs="1"/>
<xs:element ref="action" minOccurs="0" maxOccurs="1"/>
</xs:choice>
</xs:group>
<xs:complexType name="OtherwiseAction">
<xs:group ref="Node"/>
</xs:complexType>
<xs:complexType name="NotPresentAction">
<xs:group ref="Node"/>
</xs:complexType>
<xs:simpleType name="YesNoType">
<xs:restriction base="xs:NMTOKEN">
<xs:enumeration value="yes"/>
<xs:enumeration value="no"/>
</xs:restriction>
</xs:simpleType>
<xs:simpleType name="StatusType">
<xs:union>
<xs:simpleType>
<xs:restriction base="xs:NMTOKEN">
BEGIN <?xml version="1.0" encoding="UTF-8"?> <xs:schema targetNamespace="urn:ietf:params:xml:ns:cpl" xmlns="urn:ietf:params:xml:ns:cpl" xmlns:xs="http://www.w3.org/2001/XMLSchema" elementFormDefault="qualified" attributeFormDefault="unqualified"> <xs:complexType name="TopLevelActionType" abstract="true"> <xs:group ref="Node"/> </xs:complexType> <xs:element name="toplevelaction" type="TopLevelActionType"/> <xs:complexType name="ActionType" abstract="true"/> <xs:element name="action" type="ActionType"/> <xs:complexType name="SwitchType" abstract="true"/> <xs:element name="switch" type="SwitchType"/> <xs:complexType name="ModifierType" abstract="true"/> <xs:element name="modifier" type="ModifierType"/> <xs:element name="location" type="LocationType" substitutionGroup="modifier"/> <xs:element name="lookup" type="LookupType" substitutionGroup="modifier"/> <xs:element name="remove-location" type="RemoveLocationType" substitutionGroup="modifier"/> <xs:element name="sub" type="SubAction"/> <xs:group name="Node"> <xs:choice> <xs:element ref="switch" minOccurs="0" maxOccurs="1"/> <xs:element ref="modifier" minOccurs="0" maxOccurs="1"/> <xs:element ref="sub" minOccurs="0" maxOccurs="1"/> <xs:element ref="action" minOccurs="0" maxOccurs="1"/> </xs:choice> </xs:group> <xs:complexType name="OtherwiseAction"> <xs:group ref="Node"/> </xs:complexType> <xs:complexType name="NotPresentAction"> <xs:group ref="Node"/> </xs:complexType> <xs:simpleType name="YesNoType"> <xs:restriction base="xs:NMTOKEN"> <xs:enumeration value="yes"/> <xs:enumeration value="no"/> </xs:restriction> </xs:simpleType> <xs:simpleType name="StatusType"> <xs:union> <xs:simpleType> <xs:restriction base="xs:NMTOKEN">
Lennox, et al. Standards Track [Page 58] RFC 3880 CPL October 2004
Lennox, et al. Standards Track [Page 58] RFC 3880 CPL October 2004
<xs:enumeration value="busy"/>
<xs:enumeration value="notfound"/>
<xs:enumeration value="reject"/>
<xs:enumeration value="error"/>
</xs:restriction>
</xs:simpleType>
<xs:simpleType>
<xs:restriction base="xs:string"/>
</xs:simpleType>
</xs:union>
</xs:simpleType>
<xs:simpleType name="OrderingType">
<xs:restriction base="xs:NMTOKEN">
<xs:enumeration value="parallel"/>
<xs:enumeration value="sequential"/>
<xs:enumeration value="first-only"/>
</xs:restriction>
</xs:simpleType>
<xs:simpleType name="AddressFieldType">
<xs:union>
<xs:simpleType>
<xs:restriction base="xs:NMTOKEN">
<xs:enumeration value="origin"/>
<xs:enumeration value="destination"/>
<xs:enumeration value="original-destination"/>
</xs:restriction>
</xs:simpleType>
<xs:simpleType>
<xs:restriction base="xs:string"/>
</xs:simpleType>
</xs:union>
</xs:simpleType>
<xs:simpleType name="AddressSubfieldType">
<xs:union>
<xs:simpleType>
<xs:restriction base="xs:NMTOKEN">
<xs:enumeration value="address-type"/>
<xs:enumeration value="user"/>
<xs:enumeration value="host"/>
<xs:enumeration value="port"/>
<xs:enumeration value="tel"/>
<xs:enumeration value="display"/>
<xs:enumeration value="password"/>
<xs:enumeration value="alias-type"/>
</xs:restriction>
</xs:simpleType>
<xs:enumeration value="busy"/> <xs:enumeration value="notfound"/> <xs:enumeration value="reject"/> <xs:enumeration value="error"/> </xs:restriction> </xs:simpleType> <xs:simpleType> <xs:restriction base="xs:string"/> </xs:simpleType> </xs:union> </xs:simpleType> <xs:simpleType name="OrderingType"> <xs:restriction base="xs:NMTOKEN"> <xs:enumeration value="parallel"/> <xs:enumeration value="sequential"/> <xs:enumeration value="first-only"/> </xs:restriction> </xs:simpleType> <xs:simpleType name="AddressFieldType"> <xs:union> <xs:simpleType> <xs:restriction base="xs:NMTOKEN"> <xs:enumeration value="origin"/> <xs:enumeration value="destination"/> <xs:enumeration value="original-destination"/> </xs:restriction> </xs:simpleType> <xs:simpleType> <xs:restriction base="xs:string"/> </xs:simpleType> </xs:union> </xs:simpleType> <xs:simpleType name="AddressSubfieldType"> <xs:union> <xs:simpleType> <xs:restriction base="xs:NMTOKEN"> <xs:enumeration value="address-type"/> <xs:enumeration value="user"/> <xs:enumeration value="host"/> <xs:enumeration value="port"/> <xs:enumeration value="tel"/> <xs:enumeration value="display"/> <xs:enumeration value="password"/> <xs:enumeration value="alias-type"/> </xs:restriction> </xs:simpleType>
Lennox, et al. Standards Track [Page 59] RFC 3880 CPL October 2004
Lennox, et al. Standards Track [Page 59] RFC 3880 CPL October 2004
<xs:simpleType>
<xs:restriction base="xs:string"/>
</xs:simpleType>
</xs:union>
</xs:simpleType>
<xs:complexType name="AddressType">
<xs:annotation>
<xs:documentation>Exactly one of the three attributes must
appear</xs:documentation>
</xs:annotation>
<xs:group ref="Node"/>
<xs:attribute name="is" type="xs:string" use="optional"/>
<xs:attribute name="contains" type="xs:string" use="optional">
<xs:annotation>
<xs:documentation>for "display" only</xs:documentation>
</xs:annotation>
</xs:attribute>
<xs:attribute name="subdomain-of" type="xs:string"
use="optional">
<xs:annotation>
<xs:documentation>for "host", "tel" only</xs:documentation>
</xs:annotation>
</xs:attribute>
<xs:anyAttribute namespace="##any" processContents="lax"/>
</xs:complexType>
<xs:complexType name="AddressSwitchType">
<xs:complexContent>
<xs:extension base="SwitchType">
<xs:sequence>
<xs:element name="address" type="AddressType" minOccurs="0"
maxOccurs="unbounded"/>
<xs:sequence minOccurs="0">
<xs:element name="not-present" type="NotPresentAction"/>
<xs:element name="address" type="AddressType"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:element name="otherwise" type="OtherwiseAction"
minOccurs="0"/>
</xs:sequence>
<xs:attribute name="field" type="AddressFieldType"
use="required"/>
<xs:attribute name="subfield" type="AddressSubfieldType"
use="optional"/>
</xs:extension>
</xs:complexContent>
</xs:complexType>
<xs:element name="address-switch" type="AddressSwitchType"
substitutionGroup="switch"/>
<xs:simpleType> <xs:restriction base="xs:string"/> </xs:simpleType> </xs:union> </xs:simpleType> <xs:complexType name="AddressType"> <xs:annotation> <xs:documentation>Exactly one of the three attributes must appear</xs:documentation> </xs:annotation> <xs:group ref="Node"/> <xs:attribute name="is" type="xs:string" use="optional"/> <xs:attribute name="contains" type="xs:string" use="optional"> <xs:annotation> <xs:documentation>for "display" only</xs:documentation> </xs:annotation> </xs:attribute> <xs:attribute name="subdomain-of" type="xs:string" use="optional"> <xs:annotation> <xs:documentation>for "host", "tel" only</xs:documentation> </xs:annotation> </xs:attribute> <xs:anyAttribute namespace="##any" processContents="lax"/> </xs:complexType> <xs:complexType name="AddressSwitchType"> <xs:complexContent> <xs:extension base="SwitchType"> <xs:sequence> <xs:element name="address" type="AddressType" minOccurs="0" maxOccurs="unbounded"/> <xs:sequence minOccurs="0"> <xs:element name="not-present" type="NotPresentAction"/> <xs:element name="address" type="AddressType" minOccurs="0" maxOccurs="unbounded"/> </xs:sequence> <xs:element name="otherwise" type="OtherwiseAction" minOccurs="0"/> </xs:sequence> <xs:attribute name="field" type="AddressFieldType" use="required"/> <xs:attribute name="subfield" type="AddressSubfieldType" use="optional"/> </xs:extension> </xs:complexContent> </xs:complexType> <xs:element name="address-switch" type="AddressSwitchType" substitutionGroup="switch"/>
Lennox, et al. Standards Track [Page 60] RFC 3880 CPL October 2004
Lennox, et al. Standards Track [Page 60] RFC 3880 CPL October 2004
<xs:simpleType name="StringFieldType">
<xs:restriction base="xs:NMTOKEN">
<xs:enumeration value="subject"/>
<xs:enumeration value="organization"/>
<xs:enumeration value="user-agent"/>
<xs:enumeration value="display"/>
</xs:restriction>
</xs:simpleType>
<xs:complexType name="StringType">
<xs:group ref="Node"/>
<xs:attribute name="is" type="xs:string" use="optional"/>
<xs:attribute name="contains" type="xs:string" use="optional"/>
<xs:anyAttribute namespace="##any" processContents="lax"/>
</xs:complexType>
<xs:complexType name="StringSwitchType">
<xs:complexContent>
<xs:extension base="SwitchType">
<xs:sequence>
<xs:element name="string" type="StringType" minOccurs="0"
maxOccurs="unbounded"/>
<xs:sequence minOccurs="0">
<xs:element name="not-present" type="NotPresentAction"/>
<xs:element name="string" type="StringType" minOccurs="0"
maxOccurs="unbounded"/>
</xs:sequence>
<xs:element name="otherwise" type="OtherwiseAction"
minOccurs="0"/>
</xs:sequence>
<xs:attribute name="field" type="StringFieldType"
use="required">
<xs:annotation>
<xs:documentation>Strings are matched as case-insensitive
Unicode strings.</xs:documentation>
</xs:annotation>
</xs:attribute>
</xs:extension>
</xs:complexContent>
</xs:complexType>
<xs:element name="string-switch" type="StringSwitchType"
substitutionGroup="switch"/>
<xs:complexType name="LanguageType">
<xs:group ref="Node"/>
<xs:attribute name="matches" type="xs:string" use="required">
<xs:annotation>
<xs:documentation>The value of one of these parameters is a
language-tag, as defined in RFC
3066.</xs:documentation>
</xs:annotation>
<xs:simpleType name="StringFieldType"> <xs:restriction base="xs:NMTOKEN"> <xs:enumeration value="subject"/> <xs:enumeration value="organization"/> <xs:enumeration value="user-agent"/> <xs:enumeration value="display"/> </xs:restriction> </xs:simpleType> <xs:complexType name="StringType"> <xs:group ref="Node"/> <xs:attribute name="is" type="xs:string" use="optional"/> <xs:attribute name="contains" type="xs:string" use="optional"/> <xs:anyAttribute namespace="##any" processContents="lax"/> </xs:complexType> <xs:complexType name="StringSwitchType"> <xs:complexContent> <xs:extension base="SwitchType"> <xs:sequence> <xs:element name="string" type="StringType" minOccurs="0" maxOccurs="unbounded"/> <xs:sequence minOccurs="0"> <xs:element name="not-present" type="NotPresentAction"/> <xs:element name="string" type="StringType" minOccurs="0" maxOccurs="unbounded"/> </xs:sequence> <xs:element name="otherwise" type="OtherwiseAction" minOccurs="0"/> </xs:sequence> <xs:attribute name="field" type="StringFieldType" use="required"> <xs:annotation> <xs:documentation>Strings are matched as case-insensitive Unicode strings.</xs:documentation> </xs:annotation> </xs:attribute> </xs:extension> </xs:complexContent> </xs:complexType> <xs:element name="string-switch" type="StringSwitchType" substitutionGroup="switch"/> <xs:complexType name="LanguageType"> <xs:group ref="Node"/> <xs:attribute name="matches" type="xs:string" use="required"> <xs:annotation> <xs:documentation>The value of one of these parameters is a language-tag, as defined in RFC 3066.</xs:documentation> </xs:annotation>
Lennox, et al. Standards Track [Page 61] RFC 3880 CPL October 2004
Lennox, et al. Standards Track [Page 61] RFC 3880 CPL October 2004
</xs:attribute>
<xs:anyAttribute namespace="##any" processContents="lax"/>
</xs:complexType>
<xs:complexType name="LanguageSwitchType">
<xs:complexContent>
<xs:extension base="SwitchType">
<xs:sequence>
<xs:element name="language" type="LanguageType"
minOccurs="0" maxOccurs="unbounded"/>
<xs:sequence minOccurs="0">
<xs:element name="not-present" type="NotPresentAction"/>
<xs:element name="language" type="LanguageType"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:element name="otherwise" type="OtherwiseAction"
minOccurs="0"/>
</xs:sequence>
</xs:extension>
</xs:complexContent>
</xs:complexType>
<xs:element name="language-switch" type="LanguageSwitchType"
substitutionGroup="switch"/>
<xs:simpleType name="FreqType">
<xs:restriction base="xs:NMTOKEN">
<xs:pattern value="[s|S][e|E][c|C][o|O][n|N][d|D][l|L][y|Y]"/>
<xs:pattern value="[m|M][i|I][n|N][u|U][t|T][e|E][l|L][y|Y]"/>
<xs:pattern value="[h|H][o|O][u|U][r|R][l|L][y|Y]"/>
<xs:pattern value="[d|D][a|A][i|I][l|L][y|Y]"/>
<xs:pattern value="[w|W][e|E][e|E][k|K][l|L][y|Y]"/>
<xs:pattern value="[m|M][o|N][n|N][t|T][h|H][l|L][y|Y]"/>
<xs:pattern value="[y|Y][e|E][a|A][r|R][l|L][y|Y]"/>
</xs:restriction>
</xs:simpleType>
<xs:simpleType name="YearDayType">
<xs:union>
<xs:simpleType>
<xs:restriction base="xs:integer">
<xs:minInclusive value="-366"/>
<xs:maxInclusive value="-1"/>
</xs:restriction>
</xs:simpleType>
<xs:simpleType>
<xs:restriction base="xs:integer">
<xs:minInclusive value="1"/>
<xs:maxExclusive value="366"/>
</xs:restriction>
</xs:simpleType>
</xs:union>
</xs:attribute> <xs:anyAttribute namespace="##any" processContents="lax"/> </xs:complexType> <xs:complexType name="LanguageSwitchType"> <xs:complexContent> <xs:extension base="SwitchType"> <xs:sequence> <xs:element name="language" type="LanguageType" minOccurs="0" maxOccurs="unbounded"/> <xs:sequence minOccurs="0"> <xs:element name="not-present" type="NotPresentAction"/> <xs:element name="language" type="LanguageType" minOccurs="0" maxOccurs="unbounded"/> </xs:sequence> <xs:element name="otherwise" type="OtherwiseAction" minOccurs="0"/> </xs:sequence> </xs:extension> </xs:complexContent> </xs:complexType> <xs:element name="language-switch" type="LanguageSwitchType" substitutionGroup="switch"/> <xs:simpleType name="FreqType"> <xs:restriction base="xs:NMTOKEN"> <xs:pattern value="[s|S][e|E][c|C][o|O][n|N][d|D][l|L][y|Y]"/> <xs:pattern value="[m|M][i|I][n|N][u|U][t|T][e|E][l|L][y|Y]"/> <xs:pattern value="[h|H][o|O][u|U][r|R][l|L][y|Y]"/> <xs:pattern value="[d|D][a|A][i|I][l|L][y|Y]"/> <xs:pattern value="[w|W][e|E][e|E][k|K][l|L][y|Y]"/> <xs:pattern value="[m|M][o|N][n|N][t|T][h|H][l|L][y|Y]"/> <xs:pattern value="[y|Y][e|E][a|A][r|R][l|L][y|Y]"/> </xs:restriction> </xs:simpleType> <xs:simpleType name="YearDayType"> <xs:union> <xs:simpleType> <xs:restriction base="xs:integer"> <xs:minInclusive value="-366"/> <xs:maxInclusive value="-1"/> </xs:restriction> </xs:simpleType> <xs:simpleType> <xs:restriction base="xs:integer"> <xs:minInclusive value="1"/> <xs:maxExclusive value="366"/> </xs:restriction> </xs:simpleType> </xs:union>
Lennox, et al. Standards Track [Page 62] RFC 3880 CPL October 2004
Lennox, et al. Standards Track [Page 62] RFC 3880 CPL October 2004
</xs:simpleType>
<xs:simpleType name="DayType">
<xs:restriction base="xs:NMTOKEN">
<xs:pattern value="[m|M][o|O]"/>
<xs:pattern value="[t|T][u|U]"/>
<xs:pattern value="[w|W][e|E]"/>
<xs:pattern value="[t|T][h|H]"/>
<xs:pattern value="[f|F][r|R]"/>
<xs:pattern value="[s|S][a|A]"/>
<xs:pattern value="[s|S][u|U]"/>
</xs:restriction>
</xs:simpleType>
<xs:complexType name="TimeType">
<xs:annotation>
<xs:documentation>Exactly one of the two attributes "dtend" and
"duration" must occur. None of the attributes following
freq are meaningful unless freq appears.
</xs:documentation>
</xs:annotation>
<xs:group ref="Node"/>
<xs:attribute name="dtstart" type="xs:string" use="required">
<xs:annotation>
<xs:documentation>RFC 2445 DATE-TIME</xs:documentation>
</xs:annotation>
</xs:attribute>
<xs:attribute name="dtend" type="xs:string" use="optional">
<xs:annotation>
<xs:documentation>RFC 2445 DATE-TIME</xs:documentation>
</xs:annotation>
</xs:attribute>
<xs:attribute name="duration" type="xs:string" use="optional">
<xs:annotation>
<xs:documentation>RFC 2445 DURATION</xs:documentation>
</xs:annotation>
</xs:attribute>
<xs:attribute name="freq" type="FreqType" use="optional"/>
<xs:attribute name="interval" type="xs:positiveInteger"
default="1"/>
<xs:attribute name="until" type="xs:string" use="optional">
<xs:annotation>
<xs:documentation>RFC 2445 DATE-TIME</xs:documentation>
</xs:annotation>
</xs:attribute>
<xs:attribute name="count" type="xs:positiveInteger"
use="optional"/>
<xs:attribute name="bysecond" type="xs:string" use="optional">
<xs:annotation>
<xs:documentation>Comma-separated list of seconds within a
</xs:simpleType> <xs:simpleType name="DayType"> <xs:restriction base="xs:NMTOKEN"> <xs:pattern value="[m|M][o|O]"/> <xs:pattern value="[t|T][u|U]"/> <xs:pattern value="[w|W][e|E]"/> <xs:pattern value="[t|T][h|H]"/> <xs:pattern value="[f|F][r|R]"/> <xs:pattern value="[s|S][a|A]"/> <xs:pattern value="[s|S][u|U]"/> </xs:restriction> </xs:simpleType> <xs:complexType name="TimeType"> <xs:annotation> <xs:documentation>Exactly one of the two attributes "dtend" and "duration" must occur. None of the attributes following freq are meaningful unless freq appears. </xs:documentation> </xs:annotation> <xs:group ref="Node"/> <xs:attribute name="dtstart" type="xs:string" use="required"> <xs:annotation> <xs:documentation>RFC 2445 DATE-TIME</xs:documentation> </xs:annotation> </xs:attribute> <xs:attribute name="dtend" type="xs:string" use="optional"> <xs:annotation> <xs:documentation>RFC 2445 DATE-TIME</xs:documentation> </xs:annotation> </xs:attribute> <xs:attribute name="duration" type="xs:string" use="optional"> <xs:annotation> <xs:documentation>RFC 2445 DURATION</xs:documentation> </xs:annotation> </xs:attribute> <xs:attribute name="freq" type="FreqType" use="optional"/> <xs:attribute name="interval" type="xs:positiveInteger" default="1"/> <xs:attribute name="until" type="xs:string" use="optional"> <xs:annotation> <xs:documentation>RFC 2445 DATE-TIME</xs:documentation> </xs:annotation> </xs:attribute> <xs:attribute name="count" type="xs:positiveInteger" use="optional"/> <xs:attribute name="bysecond" type="xs:string" use="optional"> <xs:annotation> <xs:documentation>Comma-separated list of seconds within a
Lennox, et al. Standards Track [Page 63] RFC 3880 CPL October 2004
Lennox, et al. Standards Track [Page 63] RFC 3880 CPL October 2004
minute. Valid values are 0 to 59.</xs:documentation>
</xs:annotation>
</xs:attribute>
<xs:attribute name="byminute" type="xs:string" use="optional">
<xs:annotation>
<xs:documentation>Comma-separated list of minutes within an
hour. Valid values are 0 to 59.</xs:documentation>
</xs:annotation>
</xs:attribute>
<xs:attribute name="byhour" type="xs:string" use="optional">
<xs:annotation>
<xs:documentation>Comma-separated list of hours of the day.
Valid values are 0 to 23.</xs:documentation>
</xs:annotation>
</xs:attribute>
<xs:attribute name="byday" type="xs:string" use="optional">
<xs:annotation>
<xs:documentation>Comma-separated list of days of the week.
Valid values are "MO", "TU", "WE", "TH", "FR", "SA" and
"SU". These values are not case-sensitive. Each can be
preceded by a positive (+n) or negative (-n)
integer.</xs:documentation>
</xs:annotation>
</xs:attribute>
<xs:attribute name="bymonthday" type="xs:string" use="optional">
<xs:annotation>
<xs:documentation>Comma-separated list of days of the month.
Valid values are 1 to 31 or -31 to
-1.</xs:documentation>
</xs:annotation>
</xs:attribute>
<xs:attribute name="byyearday" type="xs:string" use="optional">
<xs:annotation>
<xs:documentation>Comma-separated list of days of the year.
Valid values are 1 to 366 or -366 to
-1.</xs:documentation>
</xs:annotation>
</xs:attribute>
<xs:attribute name="byweekno" type="xs:string" use="optional">
<xs:annotation>
<xs:documentation>Comma-separated list of ordinals specifying
weeks of the year. Valid values are 1 to 53 or -53 to
-1.</xs:documentation>
</xs:annotation>
</xs:attribute>
<xs:attribute name="bymonth" type="xs:string" use="optional">
<xs:annotation>
<xs:documentation>Comma-separated list of months of the year.
minute. Valid values are 0 to 59.</xs:documentation> </xs:annotation> </xs:attribute> <xs:attribute name="byminute" type="xs:string" use="optional"> <xs:annotation> <xs:documentation>Comma-separated list of minutes within an hour. Valid values are 0 to 59.</xs:documentation> </xs:annotation> </xs:attribute> <xs:attribute name="byhour" type="xs:string" use="optional"> <xs:annotation> <xs:documentation>Comma-separated list of hours of the day. Valid values are 0 to 23.</xs:documentation> </xs:annotation> </xs:attribute> <xs:attribute name="byday" type="xs:string" use="optional"> <xs:annotation> <xs:documentation>Comma-separated list of days of the week. Valid values are "MO", "TU", "WE", "TH", "FR", "SA" and "SU". These values are not case-sensitive. Each can be preceded by a positive (+n) or negative (-n) integer.</xs:documentation> </xs:annotation> </xs:attribute> <xs:attribute name="bymonthday" type="xs:string" use="optional"> <xs:annotation> <xs:documentation>Comma-separated list of days of the month. Valid values are 1 to 31 or -31 to -1.</xs:documentation> </xs:annotation> </xs:attribute> <xs:attribute name="byyearday" type="xs:string" use="optional"> <xs:annotation> <xs:documentation>Comma-separated list of days of the year. Valid values are 1 to 366 or -366 to -1.</xs:documentation> </xs:annotation> </xs:attribute> <xs:attribute name="byweekno" type="xs:string" use="optional"> <xs:annotation> <xs:documentation>Comma-separated list of ordinals specifying weeks of the year. Valid values are 1 to 53 or -53 to -1.</xs:documentation> </xs:annotation> </xs:attribute> <xs:attribute name="bymonth" type="xs:string" use="optional"> <xs:annotation> <xs:documentation>Comma-separated list of months of the year.
Lennox, et al. Standards Track [Page 64] RFC 3880 CPL October 2004
Lennox, et al. Standards Track [Page 64] RFC 3880 CPL October 2004
Valid values are 1 to 12.</xs:documentation>
</xs:annotation>
</xs:attribute>
<xs:attribute name="wkst" type="DayType" default="MO"/>
<xs:attribute name="bysetpos" type="YearDayType"/>
<xs:anyAttribute namespace="##any" processContents="lax"/>
</xs:complexType>
<xs:simpleType name="TZIDType">
<xs:restriction base="xs:string"/>
</xs:simpleType>
<xs:simpleType name="TZURLType">
<xs:restriction base="xs:anyURI"/>
</xs:simpleType>
<xs:complexType name="TimeSwitchType">
<xs:complexContent>
<xs:extension base="SwitchType">
<xs:sequence>
<xs:element name="time" type="TimeType" minOccurs="0"
maxOccurs="unbounded"/>
<xs:sequence minOccurs="0">
<xs:element name="not-present" type="NotPresentAction"/>
<xs:element name="time" type="TimeType" minOccurs="0"
maxOccurs="unbounded"/>
</xs:sequence>
<xs:element name="otherwise" type="OtherwiseAction"
minOccurs="0"/>
</xs:sequence>
<xs:attribute name="tzid" type="TZIDType"/>
<xs:attribute name="tzurl" type="TZURLType"/>
</xs:extension>
</xs:complexContent>
</xs:complexType>
<xs:element name="time-switch" type="TimeSwitchType"
substitutionGroup="switch"/>
<xs:simpleType name="PriorityValues">
<xs:restriction base="xs:NMTOKEN">
<xs:pattern
value="[e|E][m|M][e|E][r|R][g|G][e|E][n|N][c|C][y|Y]"/>
<xs:pattern value="[u|U][r|R][g|G][e|E][n|N][t|T]"/>
<xs:pattern value="[n|N][o|O][r|R][m|M][a|A][l|L]"/>
<xs:pattern
value="[n|N][o|O][n|N]-[u|U][r|R][g|G][e|E][n|N][t|T]"/>
</xs:restriction>
</xs:simpleType>
<xs:complexType name="PriorityType">
<xs:annotation>
<xs:documentation>Exactly one of the three attributes must
appear </xs:documentation>
Valid values are 1 to 12.</xs:documentation> </xs:annotation> </xs:attribute> <xs:attribute name="wkst" type="DayType" default="MO"/> <xs:attribute name="bysetpos" type="YearDayType"/> <xs:anyAttribute namespace="##any" processContents="lax"/> </xs:complexType> <xs:simpleType name="TZIDType"> <xs:restriction base="xs:string"/> </xs:simpleType> <xs:simpleType name="TZURLType"> <xs:restriction base="xs:anyURI"/> </xs:simpleType> <xs:complexType name="TimeSwitchType"> <xs:complexContent> <xs:extension base="SwitchType"> <xs:sequence> <xs:element name="time" type="TimeType" minOccurs="0" maxOccurs="unbounded"/> <xs:sequence minOccurs="0"> <xs:element name="not-present" type="NotPresentAction"/> <xs:element name="time" type="TimeType" minOccurs="0" maxOccurs="unbounded"/> </xs:sequence> <xs:element name="otherwise" type="OtherwiseAction" minOccurs="0"/> </xs:sequence> <xs:attribute name="tzid" type="TZIDType"/> <xs:attribute name="tzurl" type="TZURLType"/> </xs:extension> </xs:complexContent> </xs:complexType> <xs:element name="time-switch" type="TimeSwitchType" substitutionGroup="switch"/> <xs:simpleType name="PriorityValues"> <xs:restriction base="xs:NMTOKEN"> <xs:pattern value="[e|E][m|M][e|E][r|R][g|G][e|E][n|N][c|C][y|Y]"/> <xs:pattern value="[u|U][r|R][g|G][e|E][n|N][t|T]"/> <xs:pattern value="[n|N][o|O][r|R][m|M][a|A][l|L]"/> <xs:pattern value="[n|N][o|O][n|N]-[u|U][r|R][g|G][e|E][n|N][t|T]"/> </xs:restriction> </xs:simpleType> <xs:complexType name="PriorityType"> <xs:annotation> <xs:documentation>Exactly one of the three attributes must appear </xs:documentation>
Lennox, et al. Standards Track [Page 65] RFC 3880 CPL October 2004
Lennox, et al. Standards Track [Page 65] RFC 3880 CPL October 2004
</xs:annotation>
<xs:group ref="Node"/>
<xs:attribute name="less" type="PriorityValues"/>
<xs:attribute name="greater" type="PriorityValues"/>
<xs:attribute name="equal" type="xs:string">
<xs:annotation>
<xs:documentation>case-insensitive</xs:documentation>
</xs:annotation>
</xs:attribute>
<xs:anyAttribute namespace="##any" processContents="lax"/>
</xs:complexType>
<xs:complexType name="PrioritySwitchType">
<xs:complexContent>
<xs:extension base="SwitchType">
<xs:sequence>
<xs:element name="priority" type="PriorityType"
minOccurs="0" maxOccurs="unbounded"/>
<xs:sequence minOccurs="0">
<xs:element name="not-present" type="NotPresentAction"/>
<xs:element name="priority" type="PriorityType"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
<xs:element name="otherwise" type="OtherwiseAction"
minOccurs="0"/>
</xs:sequence>
</xs:extension>
</xs:complexContent>
</xs:complexType>
<xs:element name="priority-switch" type="PrioritySwitchType"
substitutionGroup="switch"/>
<xs:simpleType name="LocationPriorityType">
<xs:restriction base="xs:float">
<xs:minInclusive value="0.0"/>
<xs:maxInclusive value="1.0"/>
</xs:restriction>
</xs:simpleType>
<xs:complexType name="LocationType">
<xs:complexContent>
<xs:extension base="ModifierType">
<xs:group ref="Node"/>
<xs:attribute name="url" type="xs:anyURI" use="required"/>
<xs:attribute name="priority" type="LocationPriorityType"
use="optional" default="1.0"/>
<xs:attribute name="clear" type="YesNoType" default="no"/>
</xs:extension>
</xs:complexContent>
</xs:complexType>
<xs:complexType name="LookupType">
</xs:annotation> <xs:group ref="Node"/> <xs:attribute name="less" type="PriorityValues"/> <xs:attribute name="greater" type="PriorityValues"/> <xs:attribute name="equal" type="xs:string"> <xs:annotation> <xs:documentation>case-insensitive</xs:documentation> </xs:annotation> </xs:attribute> <xs:anyAttribute namespace="##any" processContents="lax"/> </xs:complexType> <xs:complexType name="PrioritySwitchType"> <xs:complexContent> <xs:extension base="SwitchType"> <xs:sequence> <xs:element name="priority" type="PriorityType" minOccurs="0" maxOccurs="unbounded"/> <xs:sequence minOccurs="0"> <xs:element name="not-present" type="NotPresentAction"/> <xs:element name="priority" type="PriorityType" minOccurs="0" maxOccurs="unbounded"/> </xs:sequence> <xs:element name="otherwise" type="OtherwiseAction" minOccurs="0"/> </xs:sequence> </xs:extension> </xs:complexContent> </xs:complexType> <xs:element name="priority-switch" type="PrioritySwitchType" substitutionGroup="switch"/> <xs:simpleType name="LocationPriorityType"> <xs:restriction base="xs:float"> <xs:minInclusive value="0.0"/> <xs:maxInclusive value="1.0"/> </xs:restriction> </xs:simpleType> <xs:complexType name="LocationType"> <xs:complexContent> <xs:extension base="ModifierType"> <xs:group ref="Node"/> <xs:attribute name="url" type="xs:anyURI" use="required"/> <xs:attribute name="priority" type="LocationPriorityType" use="optional" default="1.0"/> <xs:attribute name="clear" type="YesNoType" default="no"/> </xs:extension> </xs:complexContent> </xs:complexType> <xs:complexType name="LookupType">
Lennox, et al. Standards Track [Page 66] RFC 3880 CPL October 2004
Lennox, et al. Standards Track [Page 66] RFC 3880 CPL October 2004
<xs:complexContent>
<xs:extension base="ModifierType">
<xs:all>
<xs:element name="success" minOccurs="0">
<xs:complexType>
<xs:group ref="Node"/>
</xs:complexType>
</xs:element>
<xs:element name="notfound" minOccurs="0">
<xs:complexType>
<xs:group ref="Node"/>
</xs:complexType>
</xs:element>
<xs:element name="failure" minOccurs="0">
<xs:complexType>
<xs:group ref="Node"/>
</xs:complexType>
</xs:element>
</xs:all>
<xs:attribute name="source" type="xs:string"
use="required"/>
<xs:attribute name="timeout" type="xs:positiveInteger"
default="30"/>
<xs:attribute name="clear" type="YesNoType" default="no"/>
</xs:extension>
</xs:complexContent>
</xs:complexType>
<xs:complexType name="RemoveLocationType">
<xs:complexContent>
<xs:extension base="ModifierType">
<xs:group ref="Node"/>
<xs:attribute name="location" type="xs:string"
use="optional"/>
</xs:extension>
</xs:complexContent>
</xs:complexType>
<xs:complexType name="LogAction">
<xs:complexContent>
<xs:extension base="ActionType">
<xs:group ref="Node"/>
<xs:attribute name="name" type="xs:string" use="optional"/>
<xs:attribute name="comment" type="xs:string"
use="optional"/>
</xs:extension>
</xs:complexContent>
</xs:complexType>
<xs:element name="log" type="LogAction"
substitutionGroup="action"/>
<xs:complexContent> <xs:extension base="ModifierType"> <xs:all> <xs:element name="success" minOccurs="0"> <xs:complexType> <xs:group ref="Node"/> </xs:complexType> </xs:element> <xs:element name="notfound" minOccurs="0"> <xs:complexType> <xs:group ref="Node"/> </xs:complexType> </xs:element> <xs:element name="failure" minOccurs="0"> <xs:complexType> <xs:group ref="Node"/> </xs:complexType> </xs:element> </xs:all> <xs:attribute name="source" type="xs:string" use="required"/> <xs:attribute name="timeout" type="xs:positiveInteger" default="30"/> <xs:attribute name="clear" type="YesNoType" default="no"/> </xs:extension> </xs:complexContent> </xs:complexType> <xs:complexType name="RemoveLocationType"> <xs:complexContent> <xs:extension base="ModifierType"> <xs:group ref="Node"/> <xs:attribute name="location" type="xs:string" use="optional"/> </xs:extension> </xs:complexContent> </xs:complexType> <xs:complexType name="LogAction"> <xs:complexContent> <xs:extension base="ActionType"> <xs:group ref="Node"/> <xs:attribute name="name" type="xs:string" use="optional"/> <xs:attribute name="comment" type="xs:string" use="optional"/> </xs:extension> </xs:complexContent> </xs:complexType> <xs:element name="log" type="LogAction" substitutionGroup="action"/>
Lennox, et al. Standards Track [Page 67] RFC 3880 CPL October 2004
Lennox, et al. Standards Track [Page 67] RFC 3880 CPL October 2004
<xs:complexType name="IncomingType">
<xs:complexContent>
<xs:extension base="TopLevelActionType"/>
</xs:complexContent>
</xs:complexType>
<xs:element name="incoming" type="IncomingType"
substitutionGroup="toplevelaction"/>
<xs:complexType name="OutgoingType">
<xs:complexContent>
<xs:extension base="TopLevelActionType"/>
</xs:complexContent>
</xs:complexType>
<xs:element name="outgoing" type="OutgoingType"
substitutionGroup="toplevelaction"/>
<xs:complexType name="ProxyAction">
<xs:complexContent>
<xs:extension base="ActionType">
<xs:all>
<xs:element name="busy" minOccurs="0">
<xs:complexType>
<xs:group ref="Node"/>
</xs:complexType>
</xs:element>
<xs:element name="noanswer" minOccurs="0">
<xs:complexType>
<xs:group ref="Node"/>
</xs:complexType>
</xs:element>
<xs:element name="failure" minOccurs="0">
<xs:complexType>
<xs:group ref="Node"/>
</xs:complexType>
</xs:element>
<xs:element name="redirection" minOccurs="0">
<xs:complexType>
<xs:group ref="Node"/>
</xs:complexType>
</xs:element>
<xs:element name="default" minOccurs="0">
<xs:complexType>
<xs:group ref="Node"/>
</xs:complexType>
</xs:element>
</xs:all>
<xs:attribute name="timeout" type="xs:positiveInteger"
use="optional" default="20"/>
<xs:attribute name="recurse" type="YesNoType"
use="optional" default="yes"/>
<xs:complexType name="IncomingType"> <xs:complexContent> <xs:extension base="TopLevelActionType"/> </xs:complexContent> </xs:complexType> <xs:element name="incoming" type="IncomingType" substitutionGroup="toplevelaction"/> <xs:complexType name="OutgoingType"> <xs:complexContent> <xs:extension base="TopLevelActionType"/> </xs:complexContent> </xs:complexType> <xs:element name="outgoing" type="OutgoingType" substitutionGroup="toplevelaction"/> <xs:complexType name="ProxyAction"> <xs:complexContent> <xs:extension base="ActionType"> <xs:all> <xs:element name="busy" minOccurs="0"> <xs:complexType> <xs:group ref="Node"/> </xs:complexType> </xs:element> <xs:element name="noanswer" minOccurs="0"> <xs:complexType> <xs:group ref="Node"/> </xs:complexType> </xs:element> <xs:element name="failure" minOccurs="0"> <xs:complexType> <xs:group ref="Node"/> </xs:complexType> </xs:element> <xs:element name="redirection" minOccurs="0"> <xs:complexType> <xs:group ref="Node"/> </xs:complexType> </xs:element> <xs:element name="default" minOccurs="0"> <xs:complexType> <xs:group ref="Node"/> </xs:complexType> </xs:element> </xs:all> <xs:attribute name="timeout" type="xs:positiveInteger" use="optional" default="20"/> <xs:attribute name="recurse" type="YesNoType" use="optional" default="yes"/>
Lennox, et al. Standards Track [Page 68] RFC 3880 CPL October 2004
Lennox, et al. Standards Track [Page 68] RFC 3880 CPL October 2004
<xs:attribute name="ordering" type="OrderingType"
use="optional" default="parallel"/>
</xs:extension>
</xs:complexContent>
</xs:complexType>
<xs:element name="proxy" type="ProxyAction"
substitutionGroup="action"/>
<xs:complexType name="RedirectAction">
<xs:complexContent>
<xs:extension base="ActionType">
<xs:attribute name="permanent" type="YesNoType"
default="no"/>
</xs:extension>
</xs:complexContent>
</xs:complexType>
<xs:element name="redirect" type="RedirectAction"
substitutionGroup="action"/>
<xs:complexType name="RejectAction">
<xs:complexContent>
<xs:extension base="ActionType">
<xs:attribute name="status" type="StatusType"
use="required"/>
<xs:attribute name="reason" type="xs:string"
use="optional"/>
</xs:extension>
</xs:complexContent>
</xs:complexType>
<xs:element name="reject" type="RejectAction"
substitutionGroup="action"/>
<xs:complexType name="MailAction">
<xs:complexContent>
<xs:extension base="ActionType">
<xs:group ref="Node"/>
<xs:attribute name="url" type="xs:anyURI" use="required"/>
</xs:extension>
</xs:complexContent>
</xs:complexType>
<xs:element name="mail" type="MailAction"
substitutionGroup="action"/>
<xs:complexType name="SubAction">
<xs:attribute name="ref" type="xs:string" use="required"/>
</xs:complexType>
<xs:complexType name="AncillaryType"/>
<xs:complexType name="SubactionType">
<xs:group ref="Node"/>
<xs:attribute name="id" use="required"/>
</xs:complexType>
<xs:complexType name="CPLType">
<xs:attribute name="ordering" type="OrderingType" use="optional" default="parallel"/> </xs:extension> </xs:complexContent> </xs:complexType> <xs:element name="proxy" type="ProxyAction" substitutionGroup="action"/> <xs:complexType name="RedirectAction"> <xs:complexContent> <xs:extension base="ActionType"> <xs:attribute name="permanent" type="YesNoType" default="no"/> </xs:extension> </xs:complexContent> </xs:complexType> <xs:element name="redirect" type="RedirectAction" substitutionGroup="action"/> <xs:complexType name="RejectAction"> <xs:complexContent> <xs:extension base="ActionType"> <xs:attribute name="status" type="StatusType" use="required"/> <xs:attribute name="reason" type="xs:string" use="optional"/> </xs:extension> </xs:complexContent> </xs:complexType> <xs:element name="reject" type="RejectAction" substitutionGroup="action"/> <xs:complexType name="MailAction"> <xs:complexContent> <xs:extension base="ActionType"> <xs:group ref="Node"/> <xs:attribute name="url" type="xs:anyURI" use="required"/> </xs:extension> </xs:complexContent> </xs:complexType> <xs:element name="mail" type="MailAction" substitutionGroup="action"/> <xs:complexType name="SubAction"> <xs:attribute name="ref" type="xs:string" use="required"/> </xs:complexType> <xs:complexType name="AncillaryType"/> <xs:complexType name="SubactionType"> <xs:group ref="Node"/> <xs:attribute name="id" use="required"/> </xs:complexType> <xs:complexType name="CPLType">
Lennox, et al. Standards Track [Page 69] RFC 3880 CPL October 2004
Lennox, et al. Standards Track [Page 69] RFC 3880 CPL October 2004
<xs:sequence>
<xs:element name="ancillary" type="AncillaryType" minOccurs="0"
maxOccurs="1"/>
<xs:element name="subaction" type="SubactionType" minOccurs="0"
maxOccurs="unbounded"/>
<xs:element ref="toplevelaction" minOccurs="0"
maxOccurs="unbounded">
<xs:annotation>
<xs:documentation>Any toplevel action MUST NOT appear more
than once.</xs:documentation>
</xs:annotation>
</xs:element>
</xs:sequence>
</xs:complexType>
<xs:element name="cpl" type="CPLType"/>
</xs:schema>
END
<xs:sequence> <xs:element name="ancillary" type="AncillaryType" minOccurs="0" maxOccurs="1"/> <xs:element name="subaction" type="SubactionType" minOccurs="0" maxOccurs="unbounded"/> <xs:element ref="toplevelaction" minOccurs="0" maxOccurs="unbounded"> <xs:annotation> <xs:documentation>Any toplevel action MUST NOT appear more than once.</xs:documentation> </xs:annotation> </xs:element> </xs:sequence> </xs:complexType> <xs:element name="cpl" type="CPLType"/> </xs:schema> END
Normative References
Normative References
[1] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP:
Session Initiation Protocol", RFC 3261, June 2002.
[1] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002.
[2] Bray, T., Paoli, J., Sperberg-McQueen, C. M., Maler, E., and F.
Yergeau, "Extensible Markup Language (XML) 1.0 (Third Edition)",
W3C Recommendation REC-xml-20040204, World Wide Web Consortium
(W3C), February 2004. Available at http://www.w3.org/XML/.
[2] Bray, T., Paoli, J., Sperberg-McQueen, C. M., Maler, E., 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/.
[3] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[3] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[4] Hinden, R. and S. Deering, "Internet Protocol Version 6 (IPv6)
Addressing Architecture", RFC 3513, April 2003.
[4] Hinden, R. and S. Deering, "Internet Protocol Version 6 (IPv6) Addressing Architecture", RFC 3513, April 2003.
[5] Davis, M. F. and M. Duerst, "Unicode Normalization Forms",
Unicode Standard Annex #15, Unicode Consortium, April 2003.
Revision 23; part of Unicode 4.0.0. Available at
http://www.unicode.org/unicode/reports/tr15/.
[5] Davis, M. F. 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/.
[6] Davis, M. F., "Case Mappings", Unicode Standard Annex #21,
Unicode Consortium, March 2001. Revision 5; part of Unicode
3.2.0. Available at
http://www.unicode.org/unicode/reports/tr21/.
[6] Davis, M. F., "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/.
[7] Alvestrand, H., "Tags for the Identification of Languages", BCP
47, RFC 3066, January 2001.
[7] Alvestrand, H., "Tags for the Identification of Languages", BCP 47, RFC 3066, January 2001.
Lennox, et al. Standards Track [Page 70] RFC 3880 CPL October 2004
Lennox, et al. Standards Track [Page 70] RFC 3880 CPL October 2004
[8] Dawson, F. and D. Stenerson, "Internet Calendaring and
Scheduling Core Object Specification (iCalendar)", RFC 2445,
November 1998.
[8] Dawson, F. and D. Stenerson, "Internet Calendaring and Scheduling Core Object Specification (iCalendar)", RFC 2445, November 1998.
[9] Eggert, P., "Sources for Time Zone and Daylight Saving Time
Data". Available at http://www.twinsun.com/tz/tz-link.htm.
[9] Eggert, P., "Sources for Time Zone and Daylight Saving Time Data". Available at http://www.twinsun.com/tz/tz-link.htm.
[10] Mealling, M. and R. Daniel, "URI Resolution Services Necessary
for URN Resolution", RFC 2483, January 1999.
[10] Mealling, M. and R. Daniel, "URI Resolution Services Necessary for URN Resolution", RFC 2483, January 1999.
[11] Bray, T., Hollander, D., and A. Layman, "Namespaces in XML", W3C
Recommendation REC-xml-names-19990114, World Wide Web Consortium
(W3C), January 1999. Available at http://www.w3.org/TR/REC-
xml-names/.
[11] Bray, T., Hollander, D., 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/.
[12] Moats, R., "URN Syntax", RFC 2141, May 1997.
[12] Moats, R., "URN Syntax", RFC 2141, May 1997.
[13] Moats, R., "A URN Namespace for IETF Documents", RFC 2648,
August 1999.
[13] Moats, R., "A URN Namespace for IETF Documents", RFC 2648, August 1999.
[14] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, January
2004.
[14] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, January 2004.
[15] Murata, M., St.Laurent, S., and D. Kohn, "XML Media Types", RFC
3023, January 2001.
[15] Murata, M., St.Laurent, S., and D. Kohn, "XML Media Types", RFC 3023, January 2001.
Informative References
Informative References
[16] International Telecommunication Union, "Packet-based multimedia
communication systems", Recommendation H.323, Telecommunication
Standardization Sector of ITU, Geneva, Switzerland, July 2003.
[16] International Telecommunication Union, "Packet-based multimedia communication systems", Recommendation H.323, Telecommunication Standardization Sector of ITU, Geneva, Switzerland, July 2003.
[17] Lennox, J. and H. Schulzrinne, "Call Processing Language
Framework and Requirements", RFC 2824, May 2000.
[17] Lennox, J. and H. Schulzrinne, "Call Processing Language Framework and Requirements", RFC 2824, May 2000.
[18] Raggett, D., Le Hors, A., and I. Jacobs, "HTML 4.01
Specification", W3C Recommendation REC-html401-19991224, World
Wide Web Consortium (W3C), December 1999. Available at
http://www.w3.org/TR/html4/.
[18] Raggett, D., Le Hors, A., 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/.
[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 (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.
Lennox, et al. Standards Track [Page 71] RFC 3880 CPL October 2004
Lennox, et al. Standards Track [Page 71] RFC 3880 CPL October 2004
[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 (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.
[21] DeRose, S., Maler, E., Orchard, D., and B. Trafford, "XML
Linking Language (XLink) Version 1.0", W3C Recommendation REC-
xlink-20010627, World Wide Web Consortium (W3C), June 2001.
Available at http://www.w3.org/TR/xlink/.
[21] DeRose, S., Maler, E., Orchard, D., 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/.
[22] Showalter, T., "Sieve: A Mail Filtering Language", RFC 3028,
January 2001.
[22] Showalter, T., "Sieve: A Mail Filtering Language", RFC 3028, January 2001.
[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] 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.
[24] Levin, O., "H.323 Uniform Resource Locator (URL) Scheme
Registration", RFC 3508, April 2003.
[24] Levin, O., "H.323 Uniform Resource Locator (URL) Scheme Registration", RFC 3508, April 2003.
Lennox, et al. Standards Track [Page 72] RFC 3880 CPL October 2004
Lennox, et al. Standards Track [Page 72] RFC 3880 CPL October 2004
Authors' Addresses
Authors' Addresses
Jonathan Lennox Dept. of Computer Science Columbia University 1214 Amsterdam Avenue, MC 0401 New York, NY 10027 USA
Jonathan Lennox Dept. of Computer Science Columbia University 1214 Amsterdam Avenue, MC 0401 New York, NY 10027 USA
EMail: lennox@cs.columbia.edu
EMail: lennox@cs.columbia.edu
Xiaotao Wu Dept. of Computer Science Columbia University 1214 Amsterdam Avenue, MC 0401 New York, NY 10027 USA
Xiaotao Wu Dept. of Computer Science Columbia University 1214 Amsterdam Avenue, MC 0401 New York, NY 10027 USA
EMail: xiaotaow@cs.columbia.edu
EMail: xiaotaow@cs.columbia.edu
Henning Schulzrinne Dept. of Computer Science Columbia University 1214 Amsterdam Avenue, MC 0401 New York, NY 10027 USA
Henning Schulzrinne Dept. of Computer Science Columbia University 1214 Amsterdam Avenue, MC 0401 New York, NY 10027 USA
EMail: schulzrinne@cs.columbia.edu
EMail: schulzrinne@cs.columbia.edu
Lennox, et al. Standards Track [Page 73] RFC 3880 CPL October 2004
Lennox, et al. Standards Track [Page 73] RFC 3880 CPL October 2004
Full Copyright Statement
Full Copyright Statement
Copyright (C) The Internet Society (2004).
Copyright (C) The Internet Society (2004).
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
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.
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.
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
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.
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.
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.
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.
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機能のための基金は現在、インターネット協会によって提供されます。
Lennox, et al. Standards Track [Page 74]
レノックス、他 標準化過程[74ページ]
一覧
スポンサーリンク
