draft-ietf-iptel-cpl-07.txt   draft-ietf-iptel-cpl-08.txt 
Internet Engineering Task Force IPTEL WG Internet Engineering Task Force IPTEL WG
Internet Draft Lennox/Wu/Schulzrinne Internet Draft Lennox/Wu/Schulzrinne
Columbia University Columbia University
draft-ietf-iptel-cpl-07.txt draft-ietf-iptel-cpl-08.txt
August 1, 2003 August XX, 2003
Expires: February, 2004 Expires: February, 2004
CPL: A Language for User Control of Internet Telephony Services CPL: A Language for User Control of Internet Telephony Services
STATUS OF THIS MEMO STATUS OF THIS MEMO
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. all provisions of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
skipping to change at page 2, line 15 skipping to change at page 2, line 15
Table of Contents Table of Contents
1 Introduction ........................................ 4 1 Introduction ........................................ 4
1.1 Conventions of This Document ........................ 4 1.1 Conventions of This Document ........................ 4
2 Structure of CPL Scripts ............................ 5 2 Structure of CPL Scripts ............................ 5
2.1 High-level Structure ................................ 5 2.1 High-level Structure ................................ 5
2.2 Abstract Structure of a Call Processing Action ...... 5 2.2 Abstract Structure of a Call Processing Action ...... 5
2.3 Location Model ...................................... 6 2.3 Location Model ...................................... 6
2.4 XML Structure ....................................... 6 2.4 XML Structure ....................................... 6
3 Script Structure: Overview .......................... 7 3 Script Structure: Overview .......................... 7
4 Switches ............................................ 7 4 Switches ............................................ 9
4.1 Address Switches .................................... 9 4.1 Address Switches .................................... 9
4.1.1 Usage of "address-switch" with SIP .................. 12 4.1.1 Usage of "address-switch" with SIP .................. 12
4.2 String Switches ..................................... 13 4.2 String Switches ..................................... 13
4.2.1 Usage of "string-switch" with SIP ................... 14 4.2.1 Usage of "string-switch" with SIP ................... 14
4.3 Language Switches ................................... 14 4.3 Language Switches ................................... 14
4.3.1 Usage of "language-switch" with SIP ................. 15 4.3.1 Usage of "language-switch" with SIP ................. 15
4.4 Time Switches ....................................... 15 4.4 Time Switches ....................................... 15
4.4.1 iCalendar differences and implementation issues ..... 21 4.4.1 iCalendar differences and implementation issues ..... 21
4.5 Priority Switches ................................... 22 4.5 Priority Switches ................................... 23
4.5.1 Usage of "priority-switch" with SIP ................. 23 4.5.1 Usage of "priority-switch" with SIP ................. 23
5 Location Modifiers .................................. 23 5 Location Modifiers .................................. 24
5.1 Explicit Location ................................... 23 5.1 Explicit Location ................................... 24
5.1.1 Usage of "location" with SIP ........................ 24 5.1.1 Usage of "location" with SIP ........................ 25
5.2 Location Lookup ..................................... 24 5.2 Location Lookup ..................................... 25
5.2.1 Usage of "lookup" with SIP .......................... 26 5.2.1 Usage of "lookup" with SIP .......................... 26
5.3 Location Removal .................................... 26 5.3 Location Removal .................................... 26
5.3.1 Usage of "remove-location" with SIP ................. 27 5.3.1 Usage of "remove-location" with SIP ................. 27
6 Signalling Operations ............................... 27 6 Signalling Operations ............................... 27
6.1 Proxy ............................................... 27 6.1 Proxy ............................................... 27
6.1.1 Usage of "proxy" with SIP ........................... 29 6.1.1 Usage of "proxy" with SIP ........................... 30
6.2 Redirect ............................................ 30 6.2 Redirect ............................................ 30
6.2.1 Usage of "redirect" with SIP ........................ 30 6.2.1 Usage of "redirect" with SIP ........................ 31
6.3 Reject .............................................. 30 6.3 Reject .............................................. 31
6.3.1 Usage of "reject" with SIP .......................... 31 6.3.1 Usage of "reject" with SIP .......................... 32
7 Non-signalling Operations ........................... 32 7 Non-signalling Operations ........................... 32
7.1 Mail ................................................ 32 7.1 Mail ................................................ 32
7.1.1 Suggested Content of Mailed Information ............. 32 7.1.1 Suggested Content of Mailed Information ............. 33
7.2 Log ................................................. 33 7.2 Log ................................................. 34
8 Subactions .......................................... 34 8 Subactions .......................................... 34
9 Ancillary Information ............................... 35 9 Ancillary Information ............................... 36
10 Default Behavior .................................... 35 10 Default Behavior .................................... 36
11 CPL Extensions ...................................... 36 11 CPL Extensions ...................................... 37
12 Examples ............................................ 38 12 Examples ............................................ 38
12.1 Example: Call Redirect Unconditional ................ 38 12.1 Example: Call Redirect Unconditional ................ 38
12.2 Example: Call Forward Busy/No Answer ................ 38 12.2 Example: Call Forward Busy/No Answer ................ 39
12.3 Example: Call Forward: Redirect and Default ......... 38 12.3 Example: Call Forward: Redirect and Default ......... 40
12.4 Example: Call Screening ............................. 39 12.4 Example: Call Screening ............................. 41
12.5 Example: Priority and Language Routing .............. 39 12.5 Example: Priority and Language Routing .............. 42
12.6 Example: Outgoing Call Screening .................... 40 12.6 Example: Outgoing Call Screening .................... 43
12.7 Example: Time-of-day Routing ........................ 41 12.7 Example: Time-of-day Routing ........................ 44
12.8 Example: Location Filtering ......................... 41 12.8 Example: Location Filtering ......................... 45
12.9 Example: Non-signalling Operations .................. 42 12.9 Example: Non-signalling Operations .................. 46
12.10 Example: Hypothetical Extensions .................... 43 12.10 Example: Hypothetical Extensions .................... 47
12.11 Example: A Complex Example .......................... 43 12.11 Example: A Complex Example .......................... 49
13 Security Considerations ............................. 44 13 Security Considerations ............................. 50
14 IANA Considerations ................................. 44 14 IANA Considerations ................................. 51
14.1 URN Sub-Namespace Registration for 14.1 URN Sub-Namespace Registration for
urn:ietf:params:xml:ns:cpl ..................................... 46 urn:ietf:params:xml:ns:cpl ..................................... 51
14.2 MIME Registration ................................... 48 14.2 Schema registration ................................. 52
15 Acknowledgments ..................................... 49 14.3 MIME Registration ................................... 52
A An Algorithm for Resolving Time Switches ............ 49 15 Acknowledgments ..................................... 53
B Suggested Usage of CPL with H.323 ................... 51 A An Algorithm for Resolving Time Switches ............ 53
B.1 Usage of "address-switch" with H.323 ................ 51 B Suggested Usage of CPL with H.323 ................... 55
B.2 Usage of "string-switch" with H.323 ................. 53 B.1 Usage of "address-switch" with H.323 ................ 55
B.3 Usage of "language-switch" with H.323 ............... 53 B.2 Usage of "string-switch" with H.323 ................. 57
B.4 Usage of "priority-switch" with H.323 ............... 53 B.3 Usage of "language-switch" with H.323 ............... 57
B.5 Usage of "location" with H.323 ...................... 53 B.4 Usage of "priority-switch" with H.323 ............... 57
B.6 Usage of "lookup" with H.323 ........................ 53 B.5 Usage of "location" with H.323 ...................... 57
B.7 Usage of "remove-location" with H.323 ............... 54 B.6 Usage of "lookup" with H.323 ........................ 57
C The XML Schema for CPL .............................. 54 B.7 Usage of "remove-location" with H.323 ............... 58
D Changes from Earlier Versions ....................... 66 C The XML Schema for CPL .............................. 58
D.1 Changes from Draft -06 .............................. 66 D Changes from Earlier Versions ....................... 72
D.2 Changes from Draft -05 .............................. 67 D.1 Changes from Draft -07 .............................. 72
D.3 Changes from Draft -04 .............................. 67 D.2 Changes from Draft -06 .............................. 72
D.4 Changes from Draft -03 .............................. 68 D.3 Changes from Draft -05 .............................. 73
D.5 Changes from Draft -02 .............................. 69 D.4 Changes from Draft -04 .............................. 74
D.6 Changes from Draft -01 .............................. 70 D.5 Changes from Draft -03 .............................. 75
D.7 Changes from Draft -00 .............................. 71 D.6 Changes from Draft -02 .............................. 76
E Authors' Addresses .................................. 72 D.7 Changes from Draft -01 .............................. 76
F Normative References ................................ 73 D.8 Changes from Draft -00 .............................. 78
G Informative References .............................. 74 E Authors' Addresses .................................. 79
F Normative References ................................ 79
G Informative References .............................. 80
1 Introduction 1 Introduction
The Call Processing Language (CPL) is a language that can be used to The Call Processing Language (CPL) is a language that can be used to
describe and control Internet telephony services. It is not tied to describe and control Internet telephony services. It is not tied to
any particular signalling architecture or protocol; it is anticipated any particular signalling architecture or protocol; it is anticipated
that it will be used with both the Session Initiation Protocol (SIP) that it will be used with both the Session Initiation Protocol (SIP)
[1] and H.323 [16]. [1] and H.323 [16].
CPL is powerful enough to describe a large number of services and CPL is powerful enough to describe a large number of services and
skipping to change at page 7, line 40 skipping to change at page 8, line 5
remainder of the main sections of this document describe the remainder of the main sections of this document describe the
semantics of CPL, while giving its syntax informally. For the formal semantics of CPL, while giving its syntax informally. For the formal
syntax, please see the appendix. syntax, please see the appendix.
3 Script Structure: Overview 3 Script Structure: Overview
As mentioned, a CPL script consists of ancillary information, As mentioned, a CPL script consists of ancillary information,
subactions, and top-level actions. The full syntax of the "cpl" node subactions, and top-level actions. The full syntax of the "cpl" node
is given in Figure 3. is given in Figure 3.
Call processing actions, both top-level actions and sub-actions,
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
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<cpl xmlns="urn:ietf:params:xml:ns:cpl" <cpl xmlns="urn:ietf:params:xml:ns:cpl"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="urn:ietf:params:xml:ns:cpl cpl.xsd "> xsi:schemaLocation="urn:ietf:params:xml:ns:cpl cpl.xsd ">
<subaction id="voicemail"> <subaction id="voicemail">
<location url="sip:jones@voicemail.example.com"> <location url="sip:jones@voicemail.example.com">
<redirect /> <redirect />
</location> </location>
</subaction> </subaction>
<incoming> <incoming>
skipping to change at page 9, line 4 skipping to change at page 8, line 44
Tag: "cpl" Tag: "cpl"
Parameters: None Parameters: None
Sub-tags: "ancillary" See Section 9 Sub-tags: "ancillary" See Section 9
"subaction" See Section 8 "subaction" See Section 8
"outgoing" Top-level actions to take on this user's "outgoing" Top-level actions to take on this user's
outgoing calls outgoing calls
"incoming" Top-level actions to take on this user's "incoming" Top-level actions to take on this user's
incoming calls 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 sub-actions,
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
Switches represent choices a CPL script can make, based on either Switches represent choices a CPL script can make, based on either
attributes of the original call request or items independent of the attributes of the original call request or items independent of the
call. call.
All switches are arranged as a list of conditions that can match a All switches are arranged as a list of conditions that can match a
variable. Each condition corresponds to a node output; the output variable. Each condition corresponds to a node output; the output
points to the next node to execute if the condition was true. The points to the next node to execute if the condition was true. The
conditions are tried in the order they are presented in the script; conditions are tried in the order they are presented in the script;
the output corresponding to the first node to match is taken. the output corresponding to the first node to match is taken.
skipping to change at page 9, line 38 skipping to change at page 10, line 5
Such switches are not particularly useful, but might be Such switches are not particularly useful, but might be
created by tools which automatically generate CPL scripts. 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 Address switches allow a CPL script to make decisions based on one of
the addresses present in the original call request. They are the addresses present in the original call request. They are
summarized in Figure 4. summarized in Figure 4.
Address switches have two node parameters: "field", and "subfield".
The mandatory "field" parameter allows the script to specify which
address is to be considered for the switch: either the call's origin
address (field "origin"), its current destination address (field
"destination"), or its original destination (field "original-
destination"), the destination the call had before any earlier
forwarding was invoked. Servers MAY define additional field values.
The optional "subfield" specifies what 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
Node: "address-switch" Node: "address-switch"
Outputs: "address" Specific addresses to match Outputs: "address" Specific addresses to match
Parameters: "field" "origin", "destination", Parameters: "field" "origin", "destination",
or "original-destination" or "original-destination"
"subfield" "address-type", "user", "host", "subfield" "address-type", "user", "host",
"port", "tel", or "display" "port", "tel", or "display"
(also: "password" and "alias-type") (also: "password" and "alias-type")
Output: "address" Output: "address"
Parameters: "is" Exact match Parameters: "is" Exact match
"contains" Substring match (for "display" only) "contains" Substring match (for "display" only)
"subdomain-of" Sub-domain match (for "host", "tel") "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.
The optional "subfield" specifies what 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 SIP in Section 4.1.1; the subfield "alias-type" is
defined for H.323 in Appendix B.1.) If no subfield is specified, the defined for H.323 in Appendix B.1.) If no subfield is specified, the
"entire" address is matched; the precise meaning of this is defined "entire" address is matched; the precise meaning of this is defined
for each underlying signalling protocol. Servers MAY define for each underlying signalling protocol. Servers MAY define
additional subfield values. 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; address-type This indicates the type of the underlying address;
i.e., the URI scheme, if the address can be represented by i.e., the URI scheme, if the address can be represented by
skipping to change at page 12, line 30 skipping to change at page 12, line 43
address, if it is present. Because of SIP's syntax, the "destination" address, if it is present. Because of SIP's syntax, the "destination"
address field will never have a "display" subfield. address field will never have a "display" subfield.
The "address-type" subfield of an address is the URI scheme of that The "address-type" subfield of an address is the URI scheme of that
address. Other address fields depend on that "address-type". address. Other address fields depend on that "address-type".
For SIP URIs, the "user", "host", and "port" subfields correspond to For SIP URIs, the "user", "host", and "port" subfields correspond to
the "user," "host," and "port" elements of the URI syntax. (Note the "user," "host," and "port" elements of the URI syntax. (Note
that, following the definitions of RFC 3261 [1], a SIP URI which does 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 not specify a port is not the same as an explicit port 5060; the
former is indicated by an absent port subfield.) former is indicated by an absent port subfield.) The "tel" subfield
is defined to be the "user" part of the URI, with visual separators
The "tel" subfield is defined to be the "user" part of the URI, with stripped, if the "user=phone" parameter is given to the URI, or if
visual separators stripped, if the "user=phone" parameter is given to the server is otherwise configured to recognize the user part as a
the URI, or if the server is otherwise configured to recognize the telephone number. An additional subfield, "password" is defined to
user part as a telephone number. An additional subfield, "password" correspond to the "password" element of the SIP URI, and is case-
is defined to correspond to the "password" element of the SIP URI, sensitive. However, use of this field is NOT RECOMMENDED for general
and is case-sensitive. However, use of this field is NOT RECOMMENDED security reasons.
for general security reasons.
For tel URLs, the "tel" and "user" subfields are the subscriber name; For tel URLs, the "tel" and "user" subfields are the subscriber name;
in the former case, visual separators are stripped. The "host" and in the former case, visual separators are stripped. The "host" and
"port" subfields are both not present. "port" subfields are both not present.
For h323 URLs, subfields MAY be set according to the scheme described For h323 URLs, subfields MAY be set according to the scheme described
in Appendix B. in Appendix B.
For other URI schemes, only the "address-type" subfield is defined by For other URI schemes, only the "address-type" subfield is defined by
this specification; servers MAY set other pre-defined subfields, or this specification; servers MAY set other pre-defined subfields, or
skipping to change at page 15, line 37 skipping to change at page 16, line 8
header fields are ignored. header fields are ignored.
4.4 Time Switches 4.4 Time Switches
Time switches allow a CPL script to make decisions based on the time 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 and/or date the script is being executed. They are summarized in
Figure 7. Figure 7.
Time switches are independent of the underlying signalling protocol. Time switches are independent of the underlying signalling protocol.
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].
This allows CPL scripts to be generated automatically from
calendar books. It also allows us to re-use the extensive
existing work specifying time intervals.
If future standards-track documents are published that update or
obsolete RFC 2445, any changes or clarifications those documents make
to recurrence handling apply to CPL time-switches as well.
Node: "time-switch" Node: "time-switch"
Outputs: "time" Specific time to match Outputs: "time" Specific time to match
Parameters: "tzid" RFC 2445 Time Zone Identifier Parameters: "tzid" RFC 2445 Time Zone Identifier
"tzurl" RFC 2445 Time Zone URL "tzurl" RFC 2445 Time Zone URL
Output: "time" Output: "time"
Parameters: "dtstart" Start of interval (RFC 2445 DATE-TIME) Parameters: "dtstart" Start of interval (RFC 2445 DATE-TIME)
"dtend" End of interval (RFC 2445 DATE-TIME) "dtend" End of interval (RFC 2445 DATE-TIME)
"duration" Length of interval (RFC 2445 DURATION) "duration" Length of interval (RFC 2445 DURATION)
"freq" Frequency of recurrence ("secondly", "freq" Frequency of recurrence ("secondly",
skipping to change at page 16, line 34 skipping to change at page 16, line 37
"bymonthday" List of days of the month "bymonthday" List of days of the month
"byyearday" List of days of the year "byyearday" List of days of the year
"byweekno" List of weeks of the year "byweekno" List of weeks of the year
"bymonth" List of months of the year "bymonth" List of months of the year
"wkst" First day of the work week "wkst" First day of the work week
"bysetpos" List of values within "bysetpos" List of values within
set of events specified set of events specified
Figure 7: Syntax of the "time-switch" node Figure 7: Syntax of the "time-switch" node
Time switches are based closely on the specification of recurring
intervals of time in the Internet Calendaring and Scheduling Core
Object Specification (iCalendar COS), RFC 2445 [8].
This allows CPL scripts to be generated automatically from
calendar books. It also allows us to re-use the extensive
existing work specifying time intervals.
If future standards-track documents are published that update or
obsolete RFC 2445, any changes or clarifications those documents make
to recurrence handling apply to CPL time-switches as well.
An algorithm to determine whether an instant falls within a given An algorithm to determine whether an instant falls within a given
recurrence is given in Appendix A. recurrence is given in Appendix A.
The "time-switch" tag takes two optional parameters, "tzid" and 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 "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 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 time zone definition is referenced. If it begins with a forward slash
(solidus), it references a to-be-defined global time zone registry; (solidus), it references a to-be-defined global time zone registry;
otherwise it is locally-defined at the server. The "tzurl" gives a otherwise it is locally-defined at the server. The "tzurl" gives a
network location from which an up-to-date VTIMEZONE definition for network location from which an up-to-date VTIMEZONE definition for
skipping to change at page 22, line 41 skipping to change at page 23, line 11
run-time or memory requirements, and reject those that do, just as run-time or memory requirements, and reject those that do, just as
they ought to check that CPL scripts in general are not absurdly they ought to check that CPL scripts in general are not absurdly
large. large.
4.5 Priority Switches 4.5 Priority Switches
Priority switches allow a CPL script to make decisions based on the Priority switches allow a CPL script to make decisions based on the
priority specified for the original call. They are summarized in priority specified for the original call. They are summarized in
Figure 8. They are dependent on the underlying signalling protocol. Figure 8. They are dependent on the underlying signalling protocol.
Priority switches take no parameters.
The "priority" tag takes one of the three parameters "greater",
"less", and "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.
Node: "priority-switch" Node: "priority-switch"
Outputs: "priority" Specific priority to match Outputs: "priority" Specific priority to match
Parameters: None Parameters: None
Output: "priority" Output: "priority"
Parameters: "less" Match if priority is less Parameters: "less" Match if priority is less
than that specified than that specified
"greater" Match if priority is greater "greater" Match if priority is greater
than that specified than that specified
"equal" Match if priority is equal "equal" Match if priority is equal
to that specified to that specified
Figure 8: Syntax of the "priority-switch" node Figure 8: Syntax of the "priority-switch" node
Priority switches take no parameters.
The "priority" tag takes one of the three parameters "greater",
"less", and "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.
If no priority is specified in a message, the priority is considered 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 to be "normal". If an unknown priority is specified in the call, it
is considered to be equivalent to "normal" for the purposes of is considered to be equivalent to "normal" for the purposes of
"greater" and "less" comparisons, but it is compared literally for "greater" and "less" comparisons, but it is compared literally for
"equal" comparisons. "equal" comparisons.
Since every message has a priority, the "not-present" output is never Since every message has a priority, the "not-present" output is never
true for a priority switch. However, it MAY be included, to allow true for a priority switch. However, it MAY be included, to allow
switch processing to be more regular. switch processing to be more regular.
skipping to change at page 26, line 15 skipping to change at page 26, line 30
Non-URL sources indicate a source not specified by a URL which the 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 server can query for addresses to add to the location set. The only
non-URL source currently defined is "registration", which specifies non-URL source currently defined is "registration", which specifies
all the locations currently registered with the server. all the locations currently registered with the server.
The "lookup" node also has two optional parameters. The "timeout" The "lookup" node also has two optional parameters. The "timeout"
parameter specifies the time, as a positive integer number of parameter specifies the time, as a positive integer number of
seconds, the script is willing to wait for the lookup to be seconds, the script is willing to wait for the lookup to be
performed. If this is not specified, its default value is 30. The performed. If this is not specified, its default value is 30. The
"clear" parameter specifies whether the location set should be "clear" parameter specifies whether the location set should be
cleared before the new locations are added. Lookup has three cleared before the new locations are added.
outputs: "success", "notfound", and "failure". Notfound is taken if
the lookup process succeeded but did not find any locations; failure Lookup has three outputs: "success", "notfound", and "failure".
is taken if the lookup failed for some reason, including that Notfound is taken if the lookup process succeeded but did not find
specified timeout was exceeded. If a given output is not present, any locations; failure is taken if the lookup failed for some reason,
script execution terminates and the default behavior is performed. including that specified timeout was exceeded. If a given output is
not present, script execution terminates and the default behavior is
performed.
5.2.1 Usage of "lookup" with SIP 5.2.1 Usage of "lookup" with SIP
For SIP, the "registration" lookup source corresponds to the For SIP, the "registration" lookup source corresponds to the
locations registered with the server using "REGISTER" messages. locations registered with the server using "REGISTER" messages.
5.3 Location Removal 5.3 Location Removal
A CPL script can also remove locations from the location set, through 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 the use of the "remove-location" node. The syntax of this node is
skipping to change at page 26, line 48 skipping to change at page 27, line 18
Next node: Any node Next node: Any node
Parameters: "location" Location to remove Parameters: "location" Location to remove
Figure 11: Syntax of the "remove-location" node Figure 11: Syntax of the "remove-location" node
A "remove-location" node removes locations from the location set. It A "remove-location" node removes locations from the location set. It
is primarily useful following a "lookup" node. An example of this is is primarily useful following a "lookup" node. An example of this is
given in Section 12.8. given in Section 12.8.
The "remove-location" node has one optional parameter. The parameter The "remove-location" node has one optional parameter. The parameter
"location" gives the URL (or a signalling-protocol-dependent URL "location" gives the URI
pattern) of location or locations to be removed from the set. If this
parameter is not given, all locations are removed from the set. of a location to be removed from the set, in a signalling-protocol-
dependent manner. If this parameter is not given, all locations are
removed from the set.
The "remove-location" node has no explicit output tags. In the XML The "remove-location" node has no explicit output tags. In the XML
syntax, the XML "remove-location" tag directly encloses the next syntax, the XML "remove-location" tag directly encloses the next
node's tag. node's tag.
5.3.1 Usage of "remove-location" with SIP 5.3.1 Usage of "remove-location" with SIP
The location specified in the "location" parameter of the "remove- The location specified in the "location" parameter of the "remove-
location" node is matched against the location set using the standard location" node is matched against the location set using the standard
rules for SIP URI matching (as are used, e.g., to match Contact rules for SIP URI matching (as are used, e.g., to match Contact
skipping to change at page 27, line 34 skipping to change at page 28, line 7
6.1 Proxy 6.1 Proxy
Proxy causes the triggering call to be forwarded on to the currently 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 specified set of locations. The syntax of the proxy node is given in
Figure 12. Figure 12.
The specific signalling events invoked by the "proxy" node are The specific signalling events invoked by the "proxy" node are
signalling-protocol-dependent, though the general concept should signalling-protocol-dependent, though the general concept should
apply to any signalling protocol. apply to any signalling protocol.
After a proxy operation has completed, the CPL server chooses the
"best" response to the call attempt, as defined by the signalling
protocol or the server's administrative configuration rules.
If the call attempt was successful, CPL execution terminates and the
server proceeds to its default behavior (normally, to allow the call
to be set up). Otherwise, the next node corresponding to one of the
"proxy" node's outputs is taken. The "busy" output is followed if the
call was busy; "noanswer" is followed if the call was not answered
before the "timeout" parameter expired; "redirection" is followed if
the call was redirected; and "failure" is followed if the call setup
failed for any other reason.
If one of the conditions above is true, but the corresponding output
was not specified, the "default" output of the "proxy" node is
followed instead. If there is also no "default" node specified, CPL
execution terminates and the server returns to its default behavior
Node: "proxy" Node: "proxy"
Outputs: "busy" Next node if call attempt returned "busy" Outputs: "busy" Next node if call attempt returned "busy"
"noanswer" Next node if call attempt was not "noanswer" Next node if call attempt was not
answered before timeout answered before timeout
"redirection" Next node if call attempt was redirected "redirection" Next node if call attempt was redirected
"failure" Next node if call attempt failed "failure" Next node if call attempt failed
"default" Default next node for unspecified outputs "default" Default next node for unspecified outputs
Parameters: "timeout" Time to try before giving up on the Parameters: "timeout" Time to try before giving up on the
call attempt call attempt
"recurse" Whether to recursively look up "recurse" Whether to recursively look up
skipping to change at page 28, line 34 skipping to change at page 28, line 37
Parameters: none Parameters: none
Output: "failure" Output: "failure"
Parameters: none Parameters: none
Output: "default" Output: "default"
Parameters: none Parameters: none
Figure 12: Syntax of the "proxy" node Figure 12: Syntax of the "proxy" node
After a proxy operation has completed, the CPL server chooses the
"best" response to the call attempt, as defined by the signalling
protocol or the server's administrative configuration rules.
If the call attempt was successful, CPL execution terminates and the
server proceeds to its default behavior (normally, to allow the call
to be set up). Otherwise, the next node corresponding to one of the
"proxy" node's outputs is taken. The "busy" output is followed if the
call was busy; "noanswer" is followed if the call was not answered
before the "timeout" parameter expired; "redirection" is followed if
the call was redirected; and "failure" is followed if the call setup
failed for any other reason.
If one of the conditions above is true, but the corresponding output
was not specified, the "default" output of the "proxy" node is
followed instead. If there is also no "default" node specified, CPL
execution terminates and the server returns to its default behavior
(normally, to forward the best response upstream to the originator). (normally, to forward the best response upstream to the originator).
Note: CPL extensions to allow in-call or end-of-call Note: CPL extensions to allow in-call or end-of-call
operations will require an additional output, such as operations will require an additional output, such as
"success", to be added. "success", to be added.
If no locations were present in the set, or if the only locations in 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 the set were locations to which the server cannot proxy a call (for
example, "http" URLs), the "failure" output is taken. example, "http" URLs), the "failure" output is taken.
skipping to change at page 35, line 46 skipping to change at page 36, line 26
necessary for a CPL extension, it SHOULD be placed within this tag. necessary for a CPL extension, it SHOULD be placed within this tag.
The (trivial) definition of the ancillary information tag is given in The (trivial) definition of the ancillary information tag is given in
Figure 18. Figure 18.
It may be useful to include timezone definitions inside CPL It may be useful to include timezone definitions inside CPL
scripts directly, rather than referencing them externally scripts directly, rather than referencing them externally
with "tzid" and "tzurl" parameters. If it is, an extension with "tzid" and "tzurl" parameters. If it is, an extension
could be defined to include them here. could be defined to include them here.
10 Default Behavior
Tag: "ancillary" Tag: "ancillary"
Parameters: None Parameters: None
Subtags: None Subtags: None
Figure 18: Syntax of the "ancillary" tag Figure 18: Syntax of the "ancillary" tag
10 Default Behavior
When a CPL node reaches an unspecified output, either because the 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 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 contain a node, the CPL server's behavior is dependent on the current
state of script execution. This section gives the operations that state of script execution. This section gives the operations that
should be taken in each case. should be taken in each case.
no location modifications or signalling operations performed, no location modifications or signalling operations performed,
location set empty: Look up the user's location through location set empty: Look up the user's location through
whatever mechanism the server would use if no CPL script whatever mechanism the server would use if no CPL script
were in effect. Proxy, redirect, or send a rejection were in effect. Proxy, redirect, or send a rejection
skipping to change at page 37, line 4 skipping to change at page 37, line 29
proxy node, the call should be allowed to ring for the proxy node, the call should be allowed to ring for the
maximum length of time allowed by the server (or the maximum length of time allowed by the server (or the
request, if the request specified a timeout). request, if the request specified a timeout).
proxy operation previously taken: Return whatever the "best" proxy operation previously taken: Return whatever the "best"
response is of all accumulated responses to the call to response is of all accumulated responses to the call to
this point, according to the rules of the underlying this point, according to the rules of the underlying
signalling protocol. signalling protocol.
11 CPL Extensions 11 CPL Extensions
Servers MAY support additional CPL features beyond those listed in Servers MAY support additional CPL features beyond those listed in
this document. Some of the extensions which have been suggested are a this document. Some of the extensions which have been suggested are a
means of querying how a call has been authenticated; richer control means of querying how a call has been authenticated; richer control
over H.323 addressing; end-system or administrator-specific features; over H.323 addressing; end-system or administrator-specific features;
regular-expression matching for strings and addresses; and mid-call regular-expression matching for strings and addresses; and mid-call
or end-of-call controls. CPL extensions are indicated by XML or end-of-call controls.
namespaces [11]. Every extension MUST have an appropriate XML
namespace assigned to it. All XML tags and attributes that are part CPL extensions are indicated by XML namespaces [11]. Every extension
of the extension MUST be appropriately qualified so as to place them MUST have an appropriate XML namespace assigned to it. All XML tags
within that namespace. and attributes that are part of the extension MUST be appropriately
qualified so as to place them within that namespace.
Tags or attributes in a CPL script which are in the global namespace 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 (i.e., not associated with any namespace) are equivalent to tags and
attributes in the CPL namespace "urn:ietf:params:xml:ns:cpl". attributes in the CPL namespace "urn:ietf:params:xml:ns:cpl".
A CPL script SHOULD NOT specify any namespaces it does not use. For A CPL script SHOULD NOT specify any namespaces it does not use. For
compatibility with non-namespace-aware parsers, a CPL script MAY omit compatibility with non-namespace-aware parsers, a CPL script MAY omit
the base CPL namespace for a script which does not use any the base CPL namespace for a script which does not use any
extensions. extensions.
skipping to change at page 38, line 41 skipping to change at page 40, line 5
Figure 19: Example Script: Call Redirect Unconditional Figure 19: Example Script: Call Redirect Unconditional
12.2 Example: Call Forward Busy/No Answer 12.2 Example: Call Forward Busy/No Answer
The script in Figure 20 illustrates some more complex behavior. We The script in Figure 20 illustrates some more complex behavior. We
see an initial proxy attempt to one address, with further operations see an initial proxy attempt to one address, with further operations
if that fails. We also see how several outputs take the same action if that fails. We also see how several outputs take the same action
subtree, through the use of subactions. subtree, through the use of subactions.
12.3 Example: Call Forward: Redirect and Default
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
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<cpl xmlns="urn:ietf:params:xml:ns:cpl" <cpl xmlns="urn:ietf:params:xml:ns:cpl"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="urn:ietf:params:xml:ns:cpl cpl.xsd "> xsi:schemaLocation="urn:ietf:params:xml:ns:cpl cpl.xsd ">
<subaction id="voicemail"> <subaction id="voicemail">
<location url="sip:jones@voicemail.example.com"> <location url="sip:jones@voicemail.example.com">
<proxy/> <proxy/>
</location> </location>
</subaction> </subaction>
<incoming> <incoming>
skipping to change at page 39, line 29 skipping to change at page 40, line 30
<noanswer> <noanswer>
<sub ref="voicemail"/> <sub ref="voicemail"/>
</noanswer> </noanswer>
</proxy> </proxy>
</location> </location>
</incoming> </incoming>
</cpl> </cpl>
Figure 20: Example Script: Call Forward Busy/No Answer Figure 20: Example Script: Call Forward Busy/No Answer
operation -- forwarding to voicemail -- is performed. 12.3 Example: Call Forward: Redirect and Default
12.4 Example: Call Screening
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 did 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.
12.5 Example: Priority and Language Routing 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.
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-
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<cpl xmlns="urn:ietf:params:xml:ns:cpl" <cpl xmlns="urn:ietf:params:xml:ns:cpl"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="urn:ietf:params:xml:ns:cpl cpl.xsd "> xsi:schemaLocation="urn:ietf:params:xml:ns:cpl cpl.xsd ">
<incoming> <incoming>
<location url="sip:jones@jonespc.example.com"> <location url="sip:jones@jonespc.example.com">
<proxy> <proxy>
<redirection> <redirection>
<redirect/> <redirect/>
</redirection> </redirection>
skipping to change at page 40, line 26 skipping to change at page 41, line 27
<proxy/> <proxy/>
</location> </location>
</default> </default>
</proxy> </proxy>
</location> </location>
</incoming> </incoming>
</cpl> </cpl>
Figure 21: Example Script: Call Forward: Redirect and Default Figure 21: Example Script: Call Forward: Redirect and Default
12.4 Example: Call Screening
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 did not match, the script does not define any
operations. The server therefore proceeds with its default behavior,
which would presumably be to contact the user.
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<cpl xmlns="urn:ietf:params:xml:ns:cpl" <cpl xmlns="urn:ietf:params:xml:ns:cpl"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="urn:ietf:params:xml:ns:cpl cpl.xsd "> xsi:schemaLocation="urn:ietf:params:xml:ns:cpl cpl.xsd ">
<incoming> <incoming>
<address-switch field="origin" subfield="user"> <address-switch field="origin" subfield="user">
<address is="anonymous"> <address is="anonymous">
<reject status="reject" reason="I reject anonymous calls"/> <reject status="reject" reason="I reject anonymous calls"/>
</address> </address>
</address-switch> </address-switch>
</incoming> </incoming>
</cpl> </cpl>
Figure 22: Example Script: Call Screening Figure 22: Example Script: Call Screening
12.5 Example: Priority and Language Routing
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 speaking operator; other calls are proxied to an English-speaking
operator. operator.
12.6 Example: Outgoing Call Screening
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<cpl xmlns="urn:ietf:params:xml:ns:cpl" <cpl xmlns="urn:ietf:params:xml:ns:cpl"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="urn:ietf:params:xml:ns:cpl cpl.xsd "> xsi:schemaLocation="urn:ietf:params:xml:ns:cpl cpl.xsd ">
<incoming> <incoming>
<priority-switch> <priority-switch>
<priority greater="urgent"/> <priority greater="urgent"/>
<otherwise> <otherwise>
<language-switch> <language-switch>
<language matches="es"> <language matches="es">
skipping to change at page 41, line 31 skipping to change at page 43, line 32
</location> </location>
</otherwise> </otherwise>
</language-switch> </language-switch>
</otherwise> </otherwise>
</priority-switch> </priority-switch>
</incoming> </incoming>
</cpl> </cpl>
Figure 23: Example Script: Priority and Language Routing Figure 23: Example Script: Priority and Language Routing
12.6 Example: Outgoing Call Screening
The script in Figure 24 illustrates a script filtering outgoing The script in Figure 24 illustrates a script filtering outgoing
calls, in the form of a script which prevent 1-900 (premium) calls calls, in the form of a script which prevent 1-900 (premium) calls
from being placed. This script also illustrates subdomain matching. from being placed. This script also illustrates subdomain matching.
12.7 Example: Time-of-day Routing
Figure 25 illustrates time-based conditions and timezones.
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
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<cpl xmlns="urn:ietf:params:xml:ns:cpl" <cpl xmlns="urn:ietf:params:xml:ns:cpl"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="urn:ietf:params:xml:ns:cpl cpl.xsd "> xsi:schemaLocation="urn:ietf:params:xml:ns:cpl cpl.xsd ">
<outgoing> <outgoing>
<address-switch field="original-destination" subfield="tel"> <address-switch field="original-destination" subfield="tel">
<address subdomain-of="1900"> <address subdomain-of="1900">
<reject status="reject" <reject status="reject"
reason="Not allowed to make 1-900 calls."/> reason="Not allowed to make 1-900 calls."/>
</address> </address>
</address-switch> </address-switch>
</outgoing> </outgoing>
</cpl> </cpl>
Figure 24: Example Script: Outgoing Call Screening Figure 24: Example Script: Outgoing Call Screening
12.7 Example: Time-of-day Routing
Figure 25 illustrates time-based conditions and timezones.
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<cpl xmlns="urn:ietf:params:xml:ns:cpl" <cpl xmlns="urn:ietf:params:xml:ns:cpl"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="urn:ietf:params:xml:ns:cpl cpl.xsd "> xsi:schemaLocation="urn:ietf:params:xml:ns:cpl cpl.xsd ">
<incoming> <incoming>
<time-switch tzid="America/New_York" <time-switch tzid="America/New_York"
tzurl="http://zones.example.com/tz/America/New_York"> tzurl="http://zones.example.com/tz/America/New_York">
<time dtstart="20000703T090000" duration="PT8H" freq="weekly" <time dtstart="20000703T090000" duration="PT8H" freq="weekly"
byday="MO,TU,WE,TH,FR"> byday="MO,TU,WE,TH,FR">
<lookup source="registration"> <lookup source="registration">
skipping to change at page 42, line 46 skipping to change at page 45, line 31
<location url="sip:jones@voicemail.example.com"> <location url="sip:jones@voicemail.example.com">
<proxy/> <proxy/>
</location> </location>
</otherwise> </otherwise>
</time-switch> </time-switch>
</incoming> </incoming>
</cpl> </cpl>
Figure 25: Example Script: Time-of-day Routing Figure 25: Example Script: Time-of-day Routing
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. completed, call setup is allowed to proceed normally.
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<cpl xmlns="urn:ietf:params:xml:ns:cpl" <cpl xmlns="urn:ietf:params:xml:ns:cpl"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="urn:ietf:params:xml:ns:cpl cpl.xsd "> xsi:schemaLocation="urn:ietf:params:xml:ns:cpl cpl.xsd ">
<incoming> <incoming>
<string-switch field="user-agent"> <string-switch field="user-agent">
<string is="Inadequate Software SIP User Agent/0.9beta2"> <string is="Inadequate Software SIP User Agent/0.9beta2">
<lookup source="registration"> <lookup source="registration">
skipping to change at page 43, line 26 skipping to change at page 46, line 26
</remove-location> </remove-location>
</success> </success>
</lookup> </lookup>
</string> </string>
</string-switch> </string-switch>
</incoming> </incoming>
</cpl> </cpl>
Figure 26: Example Script: Location Filtering Figure 26: Example Script: Location Filtering
12.9 Example: Non-signalling Operations
Figure 27 illustrates non-signalling operations; in particular, Figure 27 illustrates non-signalling operations; in particular,
alerting a user by electronic mail if the lookup server failed. The alerting a user by electronic mail if the lookup server failed. The
primary motivation for having the "mail" node is to allow this sort primary motivation for having the "mail" node is to allow this sort
of out-of-band notification of error conditions, as the user might of out-of-band notification of error conditions, as the user might
otherwise be unaware of any problem. otherwise be unaware of any problem.
12.10 Example: Hypothetical Extensions
The example in Figure 12.10 shows a hypothetical extension which
implements distinctive ringing. The XML namespace
"http://www.example.com/distinctive-ring" specifies a new node named
"ring".
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.
12.11 Example: A Complex Example
Finally, Figure 30 is a complex example which shows the sort of
sophisticated behavior which can be achieved by combining CPL nodes.
In this case, the user attempts to have his calls reach his desk; if
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<cpl xmlns="urn:ietf:params:xml:ns:cpl" <cpl xmlns="urn:ietf:params:xml:ns:cpl"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="urn:ietf:params:xml:ns:cpl cpl.xsd "> xsi:schemaLocation="urn:ietf:params:xml:ns:cpl cpl.xsd ">
<incoming> <incoming>
<lookup <lookup
source="http://www.example.com/cgi-bin/locate.cgi?user=mary" source="http://www.example.com/cgi-bin/locate.cgi?user=mary"
timeout="8"> timeout="8">
<success> <success>
<proxy/> <proxy/>
</success> </success>
<failure> <failure>
<mail url="mailto:mary@example.com?subject=Lookup%20failed"/> <mail url="mailto:mary@example.com?subject=Lookup%20failed"/>
</failure> </failure>
</lookup> </lookup>
</incoming> </incoming>
</cpl> </cpl>
Figure 27: Example Script: Non-signalling Operations Figure 27: Example Script: Non-signalling Operations
he does not answer within a small amount of time, calls from his boss 12.10 Example: Hypothetical Extensions
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.
13 Security Considerations
CPL is designed to allow services to be specified in a manner which
prevents potentially hostile or mis-configured scripts from launching
security attacks, including denial-of-service attacks. Because script
runtime is strictly bounded by acyclicity, and because the number of
possible script operations are strictly limited, scripts should not
be able to inflict damage upon a CPL server.
Because scripts can direct users' telephone calls, the method by
which scripts are transmitted from a client to a server MUST be
strongly authenticated. Such a method is not specified in this
document.
Script servers SHOULD allow server administrators to control the The example in Figure 28 shows a hypothetical extension which
details of what CPL operations are permitted. implements distinctive ringing. The XML namespace
"http://www.example.com/distinctive-ring" specifies a new node named
"ring".
14 IANA Considerations
<?xml version="1.0" encoding="UTF-8"?> <?xml version="1.0" encoding="UTF-8"?>
<xs:schema targetNamespace="http://www.example.com/distinctive-ring" <xs:schema targetNamespace="http://www.example.com/distinctive-ring"
xmlns="http://www.example.com/distinctive-ring" xmlns="http://www.example.com/distinctive-ring"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns:CPL="urn:ietf:params:xml:ns:cpl" xmlns:CPL="urn:ietf:params:xml:ns:cpl"
elementFormDefault="qualified" elementFormDefault="qualified"
attributeFormDefault="unqualified"> attributeFormDefault="unqualified">
<xs:import namespace="urn:ietf:params:xml:ns:cpl" <xs:import namespace="urn:ietf:params:xml:ns:cpl"
schemaLocation="cpl.xsd"/> schemaLocation="cpl.xsd"/>
skipping to change at page 45, line 44 skipping to change at page 48, line 45
<address is="sip:boss@example.com"> <address is="sip:boss@example.com">
<dr:ring ringstyle="warble"/> <dr:ring ringstyle="warble"/>
</address> </address>
</address-switch> </address-switch>
</incoming> </incoming>
</cpl> </cpl>
Figure 28: Example Schema and Script: Hypothetical Distinctive- Figure 28: Example Schema and Script: Hypothetical Distinctive-
Ringing Extension Ringing Extension
This document registers a new MIME type, application/cpl+xml, and a The example in Figure 29 implements a hypothetical new attribute for
new URN per RFC 2141 [12], RFC 2648 [13], and RFC YYYY [14]. 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"?> <?xml version="1.0" encoding="UTF-8"?>
<cpl xmlns="urn:ietf:params:xml:ns:cpl" <cpl xmlns="urn:ietf:params:xml:ns:cpl"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="urn:ietf:params:xml:ns:cpl cpl.xsd "> xsi:schemaLocation="urn:ietf:params:xml:ns:cpl cpl.xsd ">
<incoming> <incoming>
<address-switch field="origin" subfield="user" <address-switch field="origin" subfield="user"
xmlns:re="http://www.example.com/regex"> xmlns:re="http://www.example.com/regex">
<address re:regex="(.*.smith|.*.jones)"> <address re:regex="(.*.smith|.*.jones)">
<reject status="reject" <reject status="reject"
reason="I don't want to talk to Smiths or Joneses"/> reason="I don't want to talk to Smiths or Joneses"/>
</address> </address>
</address-switch> </address-switch>
</incoming> </incoming>
</cpl> </cpl>
Figure 29: Example Script: Hypothetical Regular-Expression Extension Figure 29: Example Script: Hypothetical Regular-Expression Extension
[Note to RFC Editor: please replace "YYYY" above with the 12.11 Example: A Complex Example
RFC number of draft-mealling-iana-xmlns-registry, which is
currently in the RFC Editor's queue, when it is published
as an RFC.]
14.1 URN Sub-Namespace Registration for 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>
XML: Finally, Figure 30 is a complex example which shows the sort of
sophisticated behavior which 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"?> <?xml version="1.0" encoding="UTF-8"?>
<cpl xmlns="urn:ietf:params:xml:ns:cpl" <cpl xmlns="urn:ietf:params:xml:ns:cpl"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="urn:ietf:params:xml:ns:cpl cpl.xsd "> xsi:schemaLocation="urn:ietf:params:xml:ns:cpl cpl.xsd ">
<subaction id="voicemail"> <subaction id="voicemail">
<location url="sip:jones@voicemail.example.com"> <location url="sip:jones@voicemail.example.com">
<redirect /> <redirect />
</location> </location>
</subaction> </subaction>
skipping to change at page 47, line 39 skipping to change at page 50, line 39
</otherwise> </otherwise>
</address-switch> </address-switch>
</noanswer> </noanswer>
</proxy> </proxy>
</location> </location>
</incoming> </incoming>
</cpl> </cpl>
Figure 30: Example Script: A Complex Example Figure 30: Example Script: A Complex Example
13 Security Considerations
CPL is designed to allow services to be specified in a manner which
prevents potentially hostile or mis-configured scripts from launching
security attacks, including denial-of-service attacks. Because script
runtime is strictly bounded by acyclicity, and because the number of
possible script operations are strictly limited, scripts should not
be able to inflict damage upon a CPL server.
Because scripts can direct users' telephone calls, the method by
which scripts are transmitted from a client to a server MUST be
strongly authenticated. Such a method is not specified in this
document.
Script servers SHOULD allow server administrators to control the
details of what CPL operations are permitted.
14 IANA Considerations
This document registers a new MIME type, application/cpl+xml, and a
new URN per RFC 2141 [12], RFC 2648 [13], and RFC YYYY [14].
[Note to RFC Editor: please replace "YYYY" above with the
RFC number of draft-mealling-iana-xmlns-registry, which is
currently in the RFC Editor's queue, when it is published
as an RFC.]
14.1 URN Sub-Namespace Registration for 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>
XML:
BEGIN BEGIN
<?xml version="1.0"?> <?xml version="1.0"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML Basic 1.0//EN" <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML Basic 1.0//EN"
"http://www.w3.org/TR/xhtml-basic/xhtml-basic10.dtd"> "http://www.w3.org/TR/xhtml-basic/xhtml-basic10.dtd">
<html xmlns="http://www.w3.org/1999/xhtml"> <html xmlns="http://www.w3.org/1999/xhtml">
<head> <head>
<meta http-equiv="content-type" <meta http-equiv="content-type"
content="text/html;charset=iso-8859-1"/> content="text/html;charset=iso-8859-1"/>
<title>Call Processing Language Namespace</title> <title>Call Processing Language Namespace</title>
</head> </head>
<body> <body>
<h1>Namespace for Call Processing Language</h1> <h1>Namespace for Call Processing Language</h1>
<h2>application/cpl+xml</h2> <h2>urn:ietf:params:xml:ns:cpl</h2>
<p><a href="[[[URL of published RFC]]]">RFCXXXX</a>.</p> <p><a href="[[[URL of published RFC]]]">RFCXXXX</a>.</p>
</body> </body>
</html> </html>
END END
[Note to RFC Editor: please replace "[[[URL of published [Note to RFC Editor: please replace "[[[URL of published
RFC]]]" above with the official URL of this RFC at rfc- RFC]]]" above with the official URL of this RFC at rfc-
editor.org, and "XXXX" above with the number of this RFC.] editor.org, and "XXXX" above with the number of this RFC.]
14.2 MIME Registration 14.2 Schema registration
This specification registers XML Schema for CPL, as per the
guidelines in [14].
URI: please assign.
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 Section C.
14.3 MIME Registration
As an XML type, CPL's MIME registration conforms with "XML Media As an XML type, CPL's MIME registration conforms with "XML Media
Types," RFC 3023 [15]. 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
skipping to change at page 48, line 43 skipping to change at page 52, line 49
3023. 3023.
Interoperability considerations: Different CPL servers may use Interoperability considerations: Different CPL servers may use
incompatible address types. However, all potential incompatible address types. However, all potential
interoperability issues should be resolvable at the time a interoperability issues should be resolvable at the time a
script is uploaded; there should be no interoperability script is uploaded; there should be no interoperability
issues which cannot be detected until runtime. issues which cannot be detected until runtime.
Published specification: This document. Published specification: This document.
Applications which use this media type: A number of Internet Applications which use this media type: SIP proxy servers and
telephony servers, mostly using SIP. Specifically, the other telephony servers, and client software to control
authors of this specification have implemented it in their their behavior.
SIP proxy server (part of the CINEMA project).
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: Person and e-mail address for further information:
skipping to change at page 49, line 50 skipping to change at page 53, line 52
Richard Gumpertz performed a very useful last-minute technical and Richard Gumpertz performed a very useful last-minute technical and
editorial review of the specification. editorial review of the specification.
A An Algorithm for Resolving Time Switches A An Algorithm for Resolving Time Switches
The following algorithm determines whether a given instant falls The following algorithm determines whether a given instant falls
within a repetition of a "time-switch" recurrence. If the pre- within a repetition of a "time-switch" recurrence. If the pre-
processing described in Section 4.4.1 has been done, it operates in processing described in Section 4.4.1 has been done, it operates in
constant time. Open-source Java code implementing this algorithm is constant time. Open-source Java code implementing this algorithm is
available on the world wide web at available at http://www.cs.columbia.edu/~lennox/Cal-Code/ on the
<http://www.cs.columbia.edu/~lennox/Cal-Code/>. world wide web.
This algorithm is believed to be correct, but this section is non- This algorithm is believed to be correct, but this section is non-
normative. Section 4.4, and RFC 2445 [8], are the definitive normative. Section 4.4, and RFC 2445 [8], are the definitive
definitions of recurrences. definitions of recurrences.
1. Compute the time of the call, in the timezone of the time 1. Compute the time of the call, in the timezone of the time
switch. switch.
2. If the call time is earlier than "dtstart", fail NOMATCH. 2. If the call time is earlier than "dtstart", fail NOMATCH.
skipping to change at page 54, line 25 skipping to change at page 58, line 25
to remove other alias types. 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 This section includes a full XML Schema describing the XML syntax of
CPL. Every script submitted to a CPL server SHOULD comply with this CPL. Every script submitted to a CPL server SHOULD comply with this
XML Schema. When parsing scripts comply with the CPL DTD in earlier XML Schema. When parsing scripts comply with the CPL DTD in earlier
drafts, the DOCTYPE lines in the scripts should be ignored. Note that drafts, the DOCTYPE lines in the scripts should be ignored. Note that
compliance with this schema is not a sufficient condition for compliance with this schema is not a sufficient condition for
correctness of a CPL script, as many of the conditions described in correctness of a CPL script, as many of the conditions described in
this specification are not expressible in schema syntax. Figure B.4 this specification are not expressible in schema syntax. Figure 31
shows the structure of the schema. `incoming' and `outgoing' are shows the structure of the schema. `incoming' and `outgoing' are
defined as the substitutionGroup of the `toplevelaction'. All the defined as the substitutionGroup of the `toplevelaction'. All the
switches are defined as the substitutionGroup of the `switch' switches are defined as the substitutionGroup of the `switch'
element. All the actions are defined as the substitutionGroup of the element. All the actions are defined as the substitutionGroup of the
`action' element. `action' element.
+---------+ +------+ +--address +---------+ +------+ +--address
+-+ancillary| |switch|** +--------------+ | +-not-present +-+ancillary| |switch|** +--------------+ | +-not-present
| +---------+ +---+--+ **|address-switch+-+-+-address | +---------+ +---+--+ **|address-switch+-+-+-address
| | * +--------------+ +--otherwise | | * +--------------+ +--otherwise
skipping to change at page 55, line 26 skipping to change at page 59, line 26
| | * +---------------+ +--otherwise | | * +---------------+ +--otherwise
| | * +--string | | * +--string
cpl-+ | * +-------------+ | +-not-present cpl-+ | * +-------------+ | +-not-present
| | **|string-switch|-+ +-string | | **|string-switch|-+ +-string
| | * +-------------+ +--otherwise | | * +-------------+ +--otherwise
| | * +--time | | * +--time
| +--------------+ +-+--+ * +-----------+ | +-not-present | +--------------+ +-+--+ * +-----------+ | +-not-present
+-+toplevelaction+-+Node| *|time-switch|-+-+-time +-+toplevelaction+-+Node| *|time-switch|-+-+-time
+-----*--------+ +-+--+ +-----------+ +--otherwise +-----*--------+ +-+--+ +-----------+ +--otherwise
* | +--------+ +----+ * | +--------+ +----+
* | +-+location+-|Node| * | **|location+-|Node|
* | +--------+ | +--------+ +----+ * | +--------+ * +--------+ +----+
* +--------+ |-+Location+-| +------+ +-success-Node * +--------+ |-+modifier|** +------+ +-success-Node
**|incoming| | +--------+ +-+lookup+-+-notfound-Node **|incoming| | +--------+ *-|lookup+-+-notfound-Node
* +--------+ | | +------+ +-failure-Node * +--------+ | * +------+ +-failure-Node
* | +---+ | +---------------+ +----+ * | +---+ * +---------------+ +----+
* +--------+ +-+Sub+-sub +-+remove-location+-+Node| * +--------+ +-+Sub+-sub **|remove-location+-+Node|
*|outgoing| | +---+ +---------------+ +----+ *|outgoing| | +---+ +---------------+ +----+
+--------+ | +---+ +--------+ | +---+
| **|log+-Node | **|log+-Node
| * +---+ | * +---+
| * +----+ | * +----+
| +------+ **|mail+-Node | +------+ **|mail+-Node
+-+action|** +----+ +-busy-Node +-+action|** +----+ +-busy-Node
---- contains +------+ * +-----+ | ---- contains +------+ * +-----+ |
**|proxy+----+-noanswer-Node **|proxy+----+-noanswer-Node
**** substitutes * +-----+ | **** substitutes * +-----+ |
* +--------+ +-failure-Node * +--------+ +-failure-Node
**|redirect| | **|redirect| |
* +--------+ +-redirection-Node * +--------+ +-redirection-Node
* +------+ | * +------+ |
*|reject| +-default-Node *|reject| +-default-Node
+------+ +------+
Figure 31: The structure of the XML schema for CPL Figure 31: The structure of the XML schema for CPL
BEGIN
<?xml version="1.0" encoding="UTF-8"?>
<xs:schema targetNamespace="urn:ietf:params:xml:ns:cpl" <xs:schema targetNamespace="urn:ietf:params:xml:ns:cpl"
xmlns="urn:ietf:params:xml:ns:cpl" xmlns="urn:ietf:params:xml:ns:cpl"
xmlns:xs="http://www.w3.org/2001/XMLSchema" xmlns:xs="http://www.w3.org/2001/XMLSchema"
elementFormDefault="qualified" elementFormDefault="qualified"
attributeFormDefault="unqualified"> attributeFormDefault="unqualified">
<xs:complexType name="TopLevelActionType" abstract="true"> <xs:complexType name="TopLevelActionType" abstract="true">
<xs:group ref="Node"/> <xs:group ref="Node"/>
</xs:complexType> </xs:complexType>
<xs:element name="toplevelaction" type="TopLevelActionType"/> <xs:element name="toplevelaction" type="TopLevelActionType"/>
<xs:complexType name="ActionType" abstract="true"/> <xs:complexType name="ActionType" abstract="true"/>
<xs:element name="action" type="ActionType"/> <xs:element name="action" type="ActionType"/>
<xs:complexType name="SwitchType" abstract="true"/> <xs:complexType name="SwitchType" abstract="true"/>
<xs:element name="switch" type="SwitchType"/> <xs:element name="switch" type="SwitchType"/>
<xs:group name="Location"> <xs:complexType name="ModifierType" abstract="true"/>
<xs:choice> <xs:element name="modifier" type="ModifierType"/>
<xs:element name="location" type="LocationType"/> <xs:element name="location" type="LocationType"
<xs:element name="lookup" type="LookupType"/> substitutionGroup="modifier"/>
<xs:element name="remove-location" type="RemoveLocationType"/> <xs:element name="lookup" type="LookupType"
</xs:choice> substitutionGroup="modifier"/>
</xs:group> <xs:element name="remove-location" type="RemoveLocationType"
<xs:group name="Sub"> substitutionGroup="modifier"/>
<xs:all>
<xs:element name="sub" type="SubAction"/> <xs:element name="sub" type="SubAction"/>
</xs:all>
</xs:group>
<xs:group name="Node"> <xs:group name="Node">
<xs:choice> <xs:choice>
<xs:element ref="switch" minOccurs="0" maxOccurs="1"/> <xs:element ref="switch" minOccurs="0" maxOccurs="1"/>
<xs:group ref="Location" minOccurs="0" maxOccurs="1"/> <xs:element ref="modifier" minOccurs="0" maxOccurs="1"/>
<xs:group ref="Sub" minOccurs="0" maxOccurs="unbounded"/> <xs:element ref="sub" minOccurs="0" maxOccurs="1"/>
<xs:element ref="action" minOccurs="0" maxOccurs="unbounded"/> <xs:element ref="action" minOccurs="0" maxOccurs="1"/>
</xs:choice> </xs:choice>
</xs:group> </xs:group>
<xs:complexType name="OtherwiseAction"> <xs:complexType name="OtherwiseAction">
<xs:group ref="Node"/> <xs:group ref="Node"/>
</xs:complexType> </xs:complexType>
<xs:complexType name="NotPresentAction"> <xs:complexType name="NotPresentAction">
<xs:group ref="Node"/> <xs:group ref="Node"/>
</xs:complexType> </xs:complexType>
<xs:simpleType name="YesNoType"> <xs:simpleType name="YesNoType">
<xs:restriction base="xs:NMTOKEN"> <xs:restriction base="xs:NMTOKEN">
<xs:enumeration value="yes"/> <xs:enumeration value="yes"/>
<xs:enumeration value="no"/> <xs:enumeration value="no"/>
</xs:restriction> </xs:restriction>
</xs:simpleType> </xs:simpleType>
<xs:simpleType name="StatusType"> <xs:simpleType name="StatusType">
<xs:union>
<xs:simpleType>
<xs:restriction base="xs:NMTOKEN"> <xs:restriction base="xs:NMTOKEN">
<xs:pattern value="busy"/> <xs:enumeration value="busy"/>
<xs:pattern value="notfound"/> <xs:enumeration value="notfound"/>
<xs:pattern value="reject"/> <xs:enumeration value="reject"/>
<xs:pattern value="error"/> <xs:enumeration value="error"/>
<xs:pattern value="[4-6][0-9][0-9]"/>
</xs:restriction> </xs:restriction>
</xs:simpleType> </xs:simpleType>
<xs:simpleType>
<xs:restriction base="xs:string"/>
</xs:simpleType>
</xs:union>
</xs:simpleType>
<xs:simpleType name="OrderingType"> <xs:simpleType name="OrderingType">
<xs:restriction base="xs:NMTOKEN"> <xs:restriction base="xs:NMTOKEN">
<xs:enumeration value="parallel"/> <xs:enumeration value="parallel"/>
<xs:enumeration value="sequential"/> <xs:enumeration value="sequential"/>
<xs:enumeration value="first-only"/> <xs:enumeration value="first-only"/>
</xs:restriction> </xs:restriction>
</xs:simpleType> </xs:simpleType>
<xs:simpleType name="DirectionType">
<xs:restriction base="xs:string">
<xs:enumeration value="incoming"/>
<xs:enumeration value="outgoing"/>
<xs:enumeration value="both"/>
</xs:restriction>
</xs:simpleType>
<xs:simpleType name="AddressFieldType"> <xs:simpleType name="AddressFieldType">
<xs:union>
<xs:simpleType>
<xs:restriction base="xs:NMTOKEN"> <xs:restriction base="xs:NMTOKEN">
<xs:enumeration value="origin"/> <xs:enumeration value="origin"/>
<xs:enumeration value="destination"/> <xs:enumeration value="destination"/>
<xs:enumeration value="original-destination"/> <xs:enumeration value="original-destination"/>
</xs:restriction> </xs:restriction>
</xs:simpleType> </xs:simpleType>
<xs:simpleType>
<xs:restriction base="xs:string"/>
</xs:simpleType>
</xs:union>
</xs:simpleType>
<xs:simpleType name="AddressSubfieldType"> <xs:simpleType name="AddressSubfieldType">
<xs:union>
<xs:simpleType>
<xs:restriction base="xs:NMTOKEN"> <xs:restriction base="xs:NMTOKEN">
<xs:enumeration value="address-type"/> <xs:enumeration value="address-type"/>
<xs:enumeration value="user"/> <xs:enumeration value="user"/>
<xs:enumeration value="host"/> <xs:enumeration value="host"/>
<xs:enumeration value="port"/> <xs:enumeration value="port"/>
<xs:enumeration value="tel"/> <xs:enumeration value="tel"/>
<xs:enumeration value="display"/> <xs:enumeration value="display"/>
<xs:enumeration value="password"/> <xs:enumeration value="password"/>
<xs:enumeration value="alias-type"/> <xs:enumeration value="alias-type"/>
</xs:restriction> </xs:restriction>
</xs:simpleType> </xs:simpleType>
<xs:simpleType>
<xs:restriction base="xs:string"/>
</xs:simpleType>
</xs:union>
</xs:simpleType>
<xs:complexType name="AddressType"> <xs:complexType name="AddressType">
<xs:annotation>Exactly one of the three attributes must <xs:annotation>
appear</xs:annotation> <xs:documentation>Exactly one of the three attributes must
appear</xs:documentation>
</xs:annotation>
<xs:group ref="Node"/> <xs:group ref="Node"/>
<xs:attribute name="is" type="xs:string" use="optional"/> <xs:attribute name="is" type="xs:string" use="optional"/>
<xs:attribute name="contains" type="xs:string" use="optional"> <xs:attribute name="contains" type="xs:string" use="optional">
<xs:annotation>for "display" only</xs:annotation> <xs:annotation>
<xs:documentation>for "display" only</xs:documentation>
</xs:annotation>
</xs:attribute> </xs:attribute>
<xs:attribute name="subdomain-of" type="xs:string" <xs:attribute name="subdomain-of" type="xs:string"
use="optional"> use="optional">
<xs:annotation>for "host", "tel" only</xs:annotation> <xs:annotation>
<xs:documentation>for "host", "tel" only</xs:documentation>
</xs:annotation>
</xs:attribute> </xs:attribute>
<xs:anyAttribute namespace="##any" processContents="lax"/> <xs:anyAttribute namespace="##any" processContents="lax"/>
</xs:complexType> </xs:complexType>
<xs:complexType name="AddressSwitchType"> <xs:complexType name="AddressSwitchType">
<xs:complexContent>
<xs:extension base="SwitchType">
<xs:sequence> <xs:sequence>
<xs:element name="address" type="AddressType" minOccurs="0" <xs:element name="address" type="AddressType" minOccurs="0"
maxOccurs="unbounded"/> maxOccurs="unbounded"/>
<xs:sequence minOccurs="0"> <xs:sequence minOccurs="0">
<xs:element name="not-present" type="NotPresentAction"/> <xs:element name="not-present" type="NotPresentAction"/>
<xs:element name="address" type="AddressType" minOccurs="0" <xs:element name="address" type="AddressType"
maxOccurs="unbounded"/> minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence> </xs:sequence>
<xs:element name="otherwise" type="OtherwiseAction" <xs:element name="otherwise" type="OtherwiseAction"
minOccurs="0"/> minOccurs="0"/>
</xs:sequence> </xs:sequence>
<xs:attribute name="field" type="AddressFieldType" <xs:attribute name="field" type="AddressFieldType"
use="required"/> use="required"/>
<xs:attribute name="subfield" type="AddressSubfieldType" <xs:attribute name="subfield" type="AddressSubfieldType"
use="optional"/> use="optional"/>
</xs:extension>
</xs:complexContent>
</xs:complexType> </xs:complexType>
<xs:element name="address-switch" type="AddressSwitchType" <xs:element name="address-switch" type="AddressSwitchType"
substitutionGroup="switch"/> substitutionGroup="switch"/>
<xs:simpleType name="StringFieldType"> <xs:simpleType name="StringFieldType">
<xs:restriction base="xs:NMTOKEN"> <xs:restriction base="xs:NMTOKEN">
<xs:enumeration value="subject"/> <xs:enumeration value="subject"/>
<xs:enumeration value="organization"/> <xs:enumeration value="organization"/>
<xs:enumeration value="user-agent"/> <xs:enumeration value="user-agent"/>
<xs:enumeration value="display"/> <xs:enumeration value="display"/>
</xs:restriction> </xs:restriction>
</xs:simpleType> </xs:simpleType>
<xs:complexType name="StringType"> <xs:complexType name="StringType">
<xs:group ref="Node"/> <xs:group ref="Node"/>
<xs:attribute name="is" type="xs:string" use="optional"/> <xs:attribute name="is" type="xs:string" use="optional"/>
<xs:attribute name="contains" type="xs:string" use="optional"/> <xs:attribute name="contains" type="xs:string" use="optional"/>
<xs:anyAttribute namespace="##any" processContents="lax"/> <xs:anyAttribute namespace="##any" processContents="lax"/>
</xs:complexType> </xs:complexType>
<xs:complexType name="StringSwitchType"> <xs:complexType name="StringSwitchType">
<xs:complexContent>
<xs:extension base="SwitchType">
<xs:sequence> <xs:sequence>
<xs:element name="string" type="StringType" minOccurs="0" <xs:element name="string" type="StringType" minOccurs="0"
maxOccurs="unbounded"/> maxOccurs="unbounded"/>
<xs:sequence minOccurs="0"> <xs:sequence minOccurs="0">
<xs:element name="not-present" type="NotPresentAction"/> <xs:element name="not-present" type="NotPresentAction"/>
<xs:element name="string" type="StringType" minOccurs="0" <xs:element name="string" type="StringType" minOccurs="0"
maxOccurs="unbounded"/> maxOccurs="unbounded"/>
</xs:sequence> </xs:sequence>
<xs:element name="otherwise" type="OtherwiseAction" <xs:element name="otherwise" type="OtherwiseAction"
minOccurs="0"/> minOccurs="0"/>
</xs:sequence> </xs:sequence>
<xs:attribute name="field" type="StringFieldType" <xs:attribute name="field" type="StringFieldType"
use="required"> use="required">
<xs:annotation>Strings are matched as case-insensitive Unicode <xs:annotation>
strings.</xs:annotation> <xs:documentation>Strings are matched as case-insensitive
Unicode strings.</xs:documentation>
</xs:annotation>
</xs:attribute> </xs:attribute>
</xs:extension>
</xs:complexContent>
</xs:complexType> </xs:complexType>
<xs:element name="string-switch" type="StringSwitchType" <xs:element name="string-switch" type="StringSwitchType"
substitutionGroup="switch"/> substitutionGroup="switch"/>
<xs:complexType name="LanguageType"> <xs:complexType name="LanguageType">
<xs:group ref="Node"/> <xs:group ref="Node"/>
<xs:attribute name="matches" type="xs:string" use="required"> <xs:attribute name="matches" type="xs:string" use="required">
<xs:annotation>The value of one of these parameters is a <xs:annotation>
language-tag, as defined in RFC 3066.</xs:annotation> <xs:documentation>The value of one of these parameters is a
language-tag, as defined in RFC
3066.</xs:documentation>
</xs:annotation>
</xs:attribute> </xs:attribute>
<xs:anyAttribute namespace="##any" processContents="lax"/> <xs:anyAttribute namespace="##any" processContents="lax"/>
</xs:complexType> </xs:complexType>
<xs:complexType name="LanguageSwitchType"> <xs:complexType name="LanguageSwitchType">
<xs:complexContent>
<xs:extension base="SwitchType">
<xs:sequence> <xs:sequence>
<xs:element name="language" type="LanguageType" minOccurs="0" <xs:element name="language" type="LanguageType"
maxOccurs="unbounded"/> minOccurs="0" maxOccurs="unbounded"/>
<xs:sequence minOccurs="0"> <xs:sequence minOccurs="0">
<xs:element name="not-present" type="NotPresentAction"/> <xs:element name="not-present" type="NotPresentAction"/>
<xs:element name="language" type="LanguageType" minOccurs="0" <xs:element name="language" type="LanguageType"
maxOccurs="unbounded"/> minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence> </xs:sequence>
<xs:element name="otherwise" type="OtherwiseAction" <xs:element name="otherwise" type="OtherwiseAction"
minOccurs="0"/> minOccurs="0"/>
</xs:sequence> </xs:sequence>
</xs:extension>
</xs:complexContent>
</xs:complexType> </xs:complexType>
<xs:element name="language-switch" type="LanguageSwitchType" <xs:element name="language-switch" type="LanguageSwitchType"
substitutionGroup="switch"/> substitutionGroup="switch"/>
<xs:simpleType name="FreqType"> <xs:simpleType name="FreqType">
<xs:restriction base="xs:NMTOKEN"> <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="[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="[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="[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="[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="[w|W][e|E][e|E][k|K][l|L][y|Y]"/>
skipping to change at page 60, line 28 skipping to change at page 65, line 17
<xs:pattern value="[m|M][o|O]"/> <xs:pattern value="[m|M][o|O]"/>
<xs:pattern value="[t|T][u|U]"/> <xs:pattern value="[t|T][u|U]"/>
<xs:pattern value="[w|W][e|E]"/> <xs:pattern value="[w|W][e|E]"/>
<xs:pattern value="[t|T][h|H]"/> <xs:pattern value="[t|T][h|H]"/>
<xs:pattern value="[f|F][r|R]"/> <xs:pattern value="[f|F][r|R]"/>
<xs:pattern value="[s|S][a|A]"/> <xs:pattern value="[s|S][a|A]"/>
<xs:pattern value="[s|S][u|U]"/> <xs:pattern value="[s|S][u|U]"/>
</xs:restriction> </xs:restriction>
</xs:simpleType> </xs:simpleType>
<xs:complexType name="TimeType"> <xs:complexType name="TimeType">
<xs:annotation>Exactly one of the two attributes "dtend" and <xs:annotation>
"duration" must occur. None of the attributes following freq <xs:documentation>Exactly one of the two attributes "dtend" and
are meaningful unless freq appears. </xs:annotation> "duration" must occur. None of the attributes following
freq are meaningful unless freq appears.
</xs:documentation>
</xs:annotation>
<xs:group ref="Node"/> <xs:group ref="Node"/>
<xs:attribute name="dtstart" type="xs:string" use="required"> <xs:attribute name="dtstart" type="xs:string" use="required">
<xs:annotation>RFC 2445 DATE-TIME</xs:annotation> <xs:annotation>
<xs:documentation>RFC 2445 DATE-TIME</xs:documentation>
</xs:annotation>
</xs:attribute> </xs:attribute>
<xs:attribute name="dtend" type="xs:string" use="optional"> <xs:attribute name="dtend" type="xs:string" use="optional">
<xs:annotation>RFC 2445 DATE-TIME</xs:annotation> <xs:annotation>
<xs:documentation>RFC 2445 DATE-TIME</xs:documentation>
</xs:annotation>
</xs:attribute> </xs:attribute>
<xs:attribute name="duration" type="xs:string" use="optional"> <xs:attribute name="duration" type="xs:string" use="optional">
<xs:annotation>RFC 2445 DURATION</xs:annotation> <xs:annotation>
<xs:documentation>RFC 2445 DURATION</xs:documentation>
</xs:annotation>
</xs:attribute> </xs:attribute>
<xs:attribute name="freq" type="FreqType" use="optional"/> <xs:attribute name="freq" type="FreqType" use="optional"/>
<xs:attribute name="interval" type="xs:positiveInteger" <xs:attribute name="interval" type="xs:positiveInteger"
default="1"/> default="1"/>
<xs:attribute name="until" type="xs:string" use="optional"> <xs:attribute name="until" type="xs:string" use="optional">
<xs:annotation>RFC 2445 DATE-TIME</xs:annotation> <xs:annotation>
<xs:documentation>RFC 2445 DATE-TIME</xs:documentation>
</xs:annotation>
</xs:attribute> </xs:attribute>
<xs:attribute name="count" type="xs:positiveInteger" <xs:attribute name="count" type="xs:positiveInteger"
use="optional"/> use="optional"/>
<xs:attribute name="bysecond" type="xs:string" use="optional"> <xs:attribute name="bysecond" type="xs:string" use="optional">
<xs:annotation>Comma-separated list of seconds within a minute. <xs:annotation>
Valid values are 0 to 59.</xs:annotation> <xs:documentation>Comma-separated list of seconds within a
minute. Valid values are 0 to 59.</xs:documentation>
</xs:annotation>
</xs:attribute> </xs:attribute>
<xs:attribute name="byminute" type="xs:string" use="optional"> <xs:attribute name="byminute" type="xs:string" use="optional">
<xs:annotation>Comma-separated list of minutes within an hour. <xs:annotation>
Valid values are 0 to 59.</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>
<xs:attribute name="byhour" type="xs:string" use="optional"> <xs:attribute name="byhour" type="xs:string" use="optional">
<xs:annotation>Comma-separated list of hours of the day. Valid <xs:annotation>
values are 0 to 23.</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>
<xs:attribute name="byday" type="xs:string" use="optional"> <xs:attribute name="byday" type="xs:string" use="optional">
<xs:annotation>Comma-separated list of days of the week. Valid <xs:annotation>
values are "MO", "TU", "WE", "TH", "FR", "SA" and "SU". <xs:documentation>Comma-separated list of days of the week.
These values are not case-sensitive. Each can be preceded Valid values are "MO", "TU", "WE", "TH", "FR", "SA" and
by a positive (+n) or negative (-n) "SU". These values are not case-sensitive. Each can be
integer.</xs:annotation> preceded by a positive (+n) or negative (-n)
integer.</xs:documentation>
</xs:annotation>
</xs:attribute> </xs:attribute>
<xs:attribute name="bymonthday" type="xs:string" use="optional"> <xs:attribute name="bymonthday" type="xs:string" use="optional">
<xs:annotation>Comma-separated list of days of the month. Valid <xs:annotation>
values are 1 to 31 or -31 to -1.</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>
<xs:attribute name="byyearday" type="xs:string" use="optional"> <xs:attribute name="byyearday" type="xs:string" use="optional">
<xs:annotation>Comma-separated list of days of the year. Valid <xs:annotation>
values are 1 to 366 or -366 to -1.</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>
<xs:attribute name="byweekno" type="xs:string" use="optional"> <xs:attribute name="byweekno" type="xs:string" use="optional">
<xs:annotation>Comma-separated list of ordinals specifying <xs:annotation>
<xs:documentation>Comma-separated list of ordinals specifying
weeks of the year. Valid values are 1 to 53 or -53 to weeks of the year. Valid values are 1 to 53 or -53 to
-1.</xs:annotation> -1.</xs:documentation>
</xs:annotation>
</xs:attribute> </xs:attribute>
<xs:attribute name="bymonth" type="xs:string" use="optional"> <xs:attribute name="bymonth" type="xs:string" use="optional">
<xs:annotation>Comma-separated list of months of the year. <xs:annotation>
Valid values are 1 to 12.</xs:annotation> <xs:documentation>Comma-separated list of months of the year.
Valid values are 1 to 12.</xs:documentation>
</xs:annotation>
</xs:attribute> </xs:attribute>
<xs:attribute name="wkst" type="DayType" default="MO"/> <xs:attribute name="wkst" type="DayType" default="MO"/>
<xs:attribute name="bysetpos" type="YearDayType"/> <xs:attribute name="bysetpos" type="YearDayType"/>
<xs:anyAttribute namespace="##any" processContents="lax"/> <xs:anyAttribute namespace="##any" processContents="lax"/>
</xs:complexType> </xs:complexType>
<xs:simpleType name="TZIDType"> <xs:simpleType name="TZIDType">
<xs:restriction base="xs:string"/> <xs:restriction base="xs:string"/>
</xs:simpleType> </xs:simpleType>
<xs:simpleType name="TZURLType"> <xs:simpleType name="TZURLType">
<xs:restriction base="xs:anyURI"/> <xs:restriction base="xs:anyURI"/>
</xs:simpleType> </xs:simpleType>
<xs:complexType name="TimeSwitchType"> <xs:complexType name="TimeSwitchType">
<xs:complexContent>
<xs:extension base="SwitchType">
<xs:sequence> <xs:sequence>
<xs:element name="time" type="TimeType" minOccurs="0" <xs:element name="time" type="TimeType" minOccurs="0"
maxOccurs="unbounded"/> maxOccurs="unbounded"/>
<xs:sequence minOccurs="0"> <xs:sequence minOccurs="0">
<xs:element name="not-present" type="NotPresentAction"/> <xs:element name="not-present" type="NotPresentAction"/>
<xs:element name="time" type="TimeType" minOccurs="0" <xs:element name="time" type="TimeType" minOccurs="0"
maxOccurs="unbounded"/> maxOccurs="unbounded"/>
</xs:sequence> </xs:sequence>
<xs:element name="otherwise" type="OtherwiseAction" <xs:element name="otherwise" type="OtherwiseAction"
minOccurs="0"/> minOccurs="0"/>
</xs:sequence> </xs:sequence>
<xs:attribute name="tzid" type="TZIDType"/> <xs:attribute name="tzid" type="TZIDType"/>
<xs:attribute name="tzurl" type="TZURLType"/> <xs:attribute name="tzurl" type="TZURLType"/>
</xs:extension>
</xs:complexContent>
</xs:complexType> </xs:complexType>
<xs:element name="time-switch" type="TimeSwitchType" <xs:element name="time-switch" type="TimeSwitchType"
substitutionGroup="switch"/> substitutionGroup="switch"/>
<xs:simpleType name="PriorityValues"> <xs:simpleType name="PriorityValues">
<xs:restriction base="xs:NMTOKEN"> <xs:restriction base="xs:NMTOKEN">
<xs:pattern <xs:pattern
value="[e|E][m|M][e|E][r|R][g|G][e|E][n|N][c|C][y|Y]"/> 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="[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][r|R][m|M][a|A][l|L]"/>
<xs:pattern <xs:pattern
value="[n|N][o|O][n|N]-[u|U][r|R][g|G][e|E][n|N][t|T]"/> value="[n|N][o|O][n|N]-[u|U][r|R][g|G][e|E][n|N][t|T]"/>
</xs:restriction> </xs:restriction>
</xs:simpleType> </xs:simpleType>
<xs:complexType name="PriorityType"> <xs:complexType name="PriorityType">
<xs:annotation>Exactly one of the three attributes must appear <xs:annotation>
<xs:documentation>Exactly one of the three attributes must
appear </xs:documentation>
</xs:annotation> </xs:annotation>
<xs:group ref="Node"/> <xs:group ref="Node"/>
<xs:attribute name="less" type="PriorityValues"/> <xs:attribute name="less" type="PriorityValues"/>
<xs:attribute name="greater" type="PriorityValues"/> <xs:attribute name="greater" type="PriorityValues"/>
<xs:attribute name="equal" type="xs:string"> <xs:attribute name="equal" type="xs:string">
<xs:annotation>case-insensitive</xs:annotation> <xs:annotation>
<xs:documentation>case-insensitive</xs:documentation>
</xs:annotation>
</xs:attribute> </xs:attribute>
<xs:anyAttribute namespace="##any" processContents="lax"/> <xs:anyAttribute namespace="##any" processContents="lax"/>
</xs:complexType> </xs:complexType>
<xs:complexType name="PrioritySwitchType"> <xs:complexType name="PrioritySwitchType">
<xs:complexContent>
<xs:extension base="SwitchType">
<xs:sequence> <xs:sequence>
<xs:element name="priority" type="PriorityType" minOccurs="0" <xs:element name="priority" type="PriorityType"
maxOccurs="unbounded"/> minOccurs="0" maxOccurs="unbounded"/>
<xs:sequence minOccurs="0"> <xs:sequence minOccurs="0">
<xs:element name="not-present" type="NotPresentAction"/> <xs:element name="not-present" type="NotPresentAction"/>
<xs:element name="priority" type="PriorityType" minOccurs="0" <xs:element name="priority" type="PriorityType"
maxOccurs="unbounded"/> minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence> </xs:sequence>
<xs:element name="otherwise" type="OtherwiseAction" <xs:element name="otherwise" type="OtherwiseAction"
minOccurs="0"/> minOccurs="0"/>
</xs:sequence> </xs:sequence>
</xs:extension>
</xs:complexContent>
</xs:complexType> </xs:complexType>
<xs:element name="priority-switch" type="PrioritySwitchType" <xs:element name="priority-switch" type="PrioritySwitchType"
substitutionGroup="switch"/> substitutionGroup="switch"/>
<xs:simpleType name="LocationPriorityType"> <xs:simpleType name="LocationPriorityType">
<xs:restriction base="xs:float"> <xs:restriction base="xs:float">
<xs:minInclusive value="0.0"/> <xs:minInclusive value="0.0"/>
<xs:maxInclusive value="1.0"/> <xs:maxInclusive value="1.0"/>
</xs:restriction> </xs:restriction>
</xs:simpleType> </xs:simpleType>
<xs:complexType name="LocationType"> <xs:complexType name="LocationType">
<xs:complexContent>
<xs:extension base="ModifierType">
<xs:group ref="Node"/> <xs:group ref="Node"/>
<xs:attribute name="url" type="xs:anyURI" use="required"/> <xs:attribute name="url" type="xs:anyURI" use="required"/>
<xs:attribute name="priority" type="LocationPriorityType" <xs:attribute name="priority" type="LocationPriorityType"
use="optional" default="1.0"/> use="optional" default="1.0"/>
<xs:attribute name="clear" type="YesNoType" default="no"/> <xs:attribute name="clear" type="YesNoType" default="no"/>
</xs:extension>
</xs:complexContent>
</xs:complexType> </xs:complexType>
<xs:complexType name="LookupType"> <xs:complexType name="LookupType">
<xs:complexContent>
<xs:extension base="ModifierType">
<xs:all> <xs:all>
<xs:element name="success" minOccurs="0"> <xs:element name="success" minOccurs="0">
<xs:complexType> <xs:complexType>
<xs:group ref="Node"/> <xs:group ref="Node"/>
</xs:complexType> </xs:complexType>
</xs:element> </xs:element>
<xs:element name="notfound" minOccurs="0"> <xs:element name="notfound" minOccurs="0">
<xs:complexType> <xs:complexType>
<xs:group ref="Node"/> <xs:group ref="Node"/>
</xs:complexType> </xs:complexType>
</xs:element> </xs:element>
<xs:element name="failure" minOccurs="0"> <xs:element name="failure" minOccurs="0">
<xs:complexType> <xs:complexType>
<xs:group ref="Node"/> <xs:group ref="Node"/>
</xs:complexType> </xs:complexType>
</xs:element> </xs:element>
</xs:all> </xs:all>
<xs:attribute name="source" type="xs:string" use="required"/> <xs:attribute name="source" type="xs:string"
use="required"/>
<xs:attribute name="timeout" type="xs:positiveInteger" <xs:attribute name="timeout" type="xs:positiveInteger"
default="30"/> default="30"/>
<xs:attribute name="clear" type="YesNoType" default="no"/> <xs:attribute name="clear" type="YesNoType" default="no"/>
</xs:extension>
</xs:complexContent>
</xs:complexType> </xs:complexType>
<xs:complexType name="RemoveLocationType"> <xs:complexType name="RemoveLocationType">
<xs:complexContent>
<xs:extension base="ModifierType">
<xs:group ref="Node"/> <xs:group ref="Node"/>
<xs:attribute name="location" type="xs:string" use="optional"/> <xs:attribute name="location" type="xs:string"
use="optional"/>
</xs:extension>
</xs:complexContent>
</xs:complexType> </xs:complexType>
<xs:complexType name="LogAction"> <xs:complexType name="LogAction">
<xs:complexContent> <xs:complexContent>
<xs:extension base="ActionType"> <xs:extension base="ActionType">
<xs:group ref="Node"/> <xs:group ref="Node"/>
<xs:attribute name="name" type="xs:string" use="optional"/> <xs:attribute name="name" type="xs:string" use="optional"/>
<xs:attribute name="comment" type="xs:string" <xs:attribute name="comment" type="xs:string"
use="optional"/> use="optional"/>
</xs:extension> </xs:extension>
</xs:complexContent> </xs:complexContent>
skipping to change at page 66, line 7 skipping to change at page 71, line 51
<xs:element name="mail" type="MailAction" <xs:element name="mail" type="MailAction"
substitutionGroup="action"/> substitutionGroup="action"/>
<xs:complexType name="SubAction"> <xs:complexType name="SubAction">
<xs:attribute name="ref" type="xs:string" use="required"/> <xs:attribute name="ref" type="xs:string" use="required"/>
</xs:complexType> </xs:complexType>
<xs:complexType name="AncillaryType"/> <xs:complexType name="AncillaryType"/>
<xs:complexType name="SubactionType"> <xs:complexType name="SubactionType">
<xs:group ref="Node"/> <xs:group ref="Node"/>
<xs:attribute name="id" use="required"/> <xs:attribute name="id" use="required"/>
</xs:complexType> </xs:complexType>
<xs:element name="cpl"> <xs:complexType name="CPLType">
<xs:complexType>
<xs:sequence> <xs:sequence>
<xs:element name="ancillary" type="AncillaryType" <xs:element name="ancillary" type="AncillaryType" minOccurs="0"
minOccurs="0"/> maxOccurs="1"/>
<xs:element name="subaction" type="SubactionType" <xs:element name="subaction" type="SubactionType" minOccurs="0"
minOccurs="0" maxOccurs="unbounded"/>
<xs:element ref="toplevelaction" minOccurs="0"
maxOccurs="unbounded"/> 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:sequence>
</xs:complexType> </xs:complexType>
</xs:element> <xs:element name="cpl" type="CPLType"/>
</xs:schema> </xs:schema>
END
D Changes from Earlier Versions D Changes from Earlier Versions
[Note to RFC Editor: please remove this appendix before [Note to RFC Editor: please remove this appendix before
publication as an RFC.] publication as an RFC.]
D.1 Changes from Draft -06 D.1 Changes from Draft -07
o Added Intellectual Property Statement.
o Included filenames in the references to I-Ds.
o Modified remove-location node description.
o Moved the CPL example scripts out of the IANA registration
part.
o Fixed bugs in URN registration XML.
o Added an IANA registration for CPL schema.
o Fixed bugs in the CPL schema for the format of xs:annotations
element.
o Modified CPL schema for backward compatibilities to the CPL
DTD.
D.2 Changes from Draft -06
The changebars in the Postscript and PDF versions of this document The changebars in the Postscript and PDF versions of this document
indicate significant changes from this version. indicate significant changes from this version.
o Added Xiaotao Wu as a co-author. o Added Xiaotao Wu as a co-author.
o Converted CPL DTD to CPL XML Schema. o Converted CPL DTD to CPL XML Schema.
o Dropped all features dependent on caller preferences and o Dropped all features dependent on caller preferences and
callee capabilities. callee capabilities.
skipping to change at page 67, line 16 skipping to change at page 73, line 37
accidentally omitted when sub-day recurrences were re-added in accidentally omitted when sub-day recurrences were re-added in
draft -05. draft -05.
o Clarified the usages of "lookup" and "remove-location" with o Clarified the usages of "lookup" and "remove-location" with
SIP, and "remove-location" with H.323. SIP, and "remove-location" with H.323.
o Updated address of the IPTel working group's mailing list. o Updated address of the IPTel working group's mailing list.
o Improved wording, cleaned up formatting, and corrected typos. o Improved wording, cleaned up formatting, and corrected typos.
D.2 Changes from Draft -05 D.3 Changes from Draft -05
o Clarified that switch nodes are allowed to be degenerate -- o Clarified that switch nodes are allowed to be degenerate --
they can have no outputs, and they can have only an they can have no outputs, and they can have only an
"otherwise" output. "otherwise" output.
o Clarified the (non-) usage of the special language-range "*". o Clarified the (non-) usage of the special language-range "*".
o Clarified that the Candidate Start Time can be equal to the o Clarified that the Candidate Start Time can be equal to the
call time. call time.
skipping to change at page 67, line 39 skipping to change at page 74, line 12
o Added DTD entries for the "time-switch" attributes re-added in o Added DTD entries for the "time-switch" attributes re-added in
draft -05. draft -05.
o Updated the reference to ISO 8601 to cite 8601:2000. o Updated the reference to ISO 8601 to cite 8601:2000.
o Updated all H.323 references to cite H.323v4. o Updated all H.323 references to cite H.323v4.
o Corrected some spelling errors. o Corrected some spelling errors.
D.3 Changes from Draft -04 D.4 Changes from Draft -04
o Broke out language switches into their own switch node. o Broke out language switches into their own switch node.
o Restored the full iCalendar COS recurrence specification. o Restored the full iCalendar COS recurrence specification.
Added text describing the consequences of this for Added text describing the consequences of this for
implementors, and expanded somewhat on the recurrence implementors, and expanded somewhat on the recurrence
algorithm. algorithm.
o Clarified when time zones are resolved. o Clarified when time zones are resolved.
skipping to change at page 68, line 35 skipping to change at page 75, line 10
can trigger a default action, just like anything else. can trigger a default action, just like anything else.
o Clarified that the time-switch resolution algorithm is non- o Clarified that the time-switch resolution algorithm is non-
normative. normative.
o Updated references to previously-unpublished RFCs, now o Updated references to previously-unpublished RFCs, now
published. published.
o Thanked Richard Gumpertz. o Thanked Richard Gumpertz.
D.4 Changes from Draft -03 D.5 Changes from Draft -03
o Removed an obsolete reference to a usage in examples which o Removed an obsolete reference to a usage in examples which
wasn't actually used anywhere. wasn't actually used anywhere.
o Added forward references to "remove-location", "mail" and o Added forward references to "remove-location", "mail" and
"log", as well as "location", in the XML syntax as examples of "log", as well as "location", in the XML syntax as examples of
nodes that don't have explicit output tags. nodes that don't have explicit output tags.
o Made the usage of some terminology more consistent: "output" o Made the usage of some terminology more consistent: "output"
vs. "next node"; "action" vs. "operation" vs. "behavior"; vs. "next node"; "action" vs. "operation" vs. "behavior";
skipping to change at page 69, line 33 skipping to change at page 76, line 7
extensions only. extensions only.
o Expunged some references to sub-daily recurrences which had o Expunged some references to sub-daily recurrences which had
accidentally been left in the text. accidentally been left in the text.
o Updated bibliography to refer to the latest versions of the o Updated bibliography to refer to the latest versions of the
cited documents. cited documents.
o Fixed a number of typographical errors. o Fixed a number of typographical errors.
D.5 Changes from Draft -02 D.6 Changes from Draft -02
o Reduced time-switches from the full iCal recurrence to an iCal o Reduced time-switches from the full iCal recurrence to an iCal
subset. Added an appendix giving an algorithm to resolve subset. Added an appendix giving an algorithm to resolve
time-switches. time-switches.
o Added the extension mechanism. o Added the extension mechanism.
o Made explicit how each node is dependent on protocol handling. o Made explicit how each node is dependent on protocol handling.
Separated out protocol-specific information -- for SIP in Separated out protocol-specific information -- for SIP in
subsections of the main text, for H.323 in a non-normative subsections of the main text, for H.323 in a non-normative
skipping to change at page 70, line 29 skipping to change at page 76, line 51
o Pointed out that log names are logical names, and should not o Pointed out that log names are logical names, and should not
be interpreted as verbatim filenames. be interpreted as verbatim filenames.
o Added some examples. o Added some examples.
o Clarified some wording. o Clarified some wording.
o Fixed some typographical errors. o Fixed some typographical errors.
D.6 Changes from Draft -01 D.7 Changes from Draft -01
o Completely re-wrote changes to time switches: they are now o Completely re-wrote changes to time switches: they are now
based on iCal rather than on crontab. based on iCal rather than on crontab.
o Timezone references are now defined within time switches o Timezone references are now defined within time switches
rather than in the ancillary section. The ancillary section is rather than in the ancillary section. The ancillary section is
now empty, but still defined for future use. To facilitate now empty, but still defined for future use. To facilitate
this, an explicit "ancillary" tag was added. this, an explicit "ancillary" tag was added.
o Added XML document type identifiers (the public identifier and o Added XML document type identifiers (the public identifier and
the namespace), and MIME registration information. the namespace), and MIME registration information.
skipping to change at page 71, line 37 skipping to change at page 78, line 11
servers. servers.
o Updated reference to RFC 2824 now that it has been published. o Updated reference to RFC 2824 now that it has been published.
o Added explanatory text to the introduction to types of nodes. o Added explanatory text to the introduction to types of nodes.
o Numerous minor clarifications and wording changes. o Numerous minor clarifications and wording changes.
o Fixed copy-and-paste errors, typos. o Fixed copy-and-paste errors, typos.
D.7 Changes from Draft -00 D.8 Changes from Draft -00
o Added high-level structure; script doesn't just start at a o Added high-level structure; script doesn't just start at a
first action. first action.
o Added a section giving a high-level explanation of the o Added a section giving a high-level explanation of the
location model. location model.
o Added informal syntax specifications for each tag so people o Added informal syntax specifications for each tag so people
don't have to try to understand a DTD to figure out the don't have to try to understand a DTD to figure out the
syntax. syntax.
skipping to change at page 74, line 22 skipping to change at page 80, line 44
[11] T. Bray, D. Hollander, and A. Layman, "Namespaces in XML," W3C [11] T. Bray, D. Hollander, and A. Layman, "Namespaces in XML," W3C
Recommendation REC-xml-names-19900114, World Wide Web Consortium Recommendation REC-xml-names-19900114, World Wide Web Consortium
(W3C), Jan. 1999. Available at http://www.w3.org/TR/REC-xml-names/. (W3C), Jan. 1999. Available at http://www.w3.org/TR/REC-xml-names/.
[12] R. Moats, "URN syntax," RFC 2141, Internet Engineering Task [12] R. Moats, "URN syntax," RFC 2141, Internet Engineering Task
Force, May 1997. Force, May 1997.
[13] R. Moats, "A URN namespace for IETF documents," RFC 2648, [13] R. Moats, "A URN namespace for IETF documents," RFC 2648,
Internet Engineering Task Force, Aug. 1999. Internet Engineering Task Force, Aug. 1999.
[14] M. Mealling, "The IETF XML registry," internet draft, Internet [14] M. Mealling, "The IETF XML registry," Internet Draft draft-
Engineering Task Force, June 2003. Work in progress. mealling-iana-xmlns-registry-05.txt, Internet Engineering Task Force,
June 2003. Work in progress.
[15] M. Murata, S. S. Laurent, and D. Kohn, "XML media types," RFC [15] M. Murata, S. S. Laurent, and D. Kohn, "XML media types," RFC
3023, Internet Engineering Task Force, Jan. 2001. 3023, Internet Engineering Task Force, Jan. 2001.
G Informative References G Informative References
[16] International Telecommunication Union, "Packet based multimedia [16] International Telecommunication Union, "Packet based multimedia
communication systems," Recommendation H.323, Telecommunication communication systems," Recommendation H.323, Telecommunication
Standardization Sector of ITU, Geneva, Switzerland, Nov. 2000. Standardization Sector of ITU, Geneva, Switzerland, Nov. 2000.
[17] J. Lennox and H. Schulzrinne, "Call processing language [17] J. Lennox and H. Schulzrinne, "Call processing language
framework and requirements," RFC 2824, Internet Engineering Task framework and requirements," RFC 2824, Internet Engineering Task
Force, May 2000. Force, May 2000.
[18] D. Raggett, A. Le Hors, and I. Jacobs, "HTML 4.01 [18] D. Raggett, A. Le Hors, and I. Jacobs, "HTML 4.01
specification," W3C Recommendation REC-html401-19991224, World Wide specification," W3C Recommendation REC-html401-19991224, World Wide
skipping to change at page 75, line 22 skipping to change at page 81, line 45
Internet Engineering Task Force, Jan. 2001. Internet Engineering Task Force, Jan. 2001.
[23] International Telecommunication Union, "Digital subscriber [23] International Telecommunication Union, "Digital subscriber
signalling system no. 1 (DSS 1) - ISDN user-network interface layer 3 signalling system no. 1 (DSS 1) - ISDN user-network interface layer 3
specification for basic call control," Recommendation Q.931, specification for basic call control," Recommendation Q.931,
International Telecommunication Union, Geneva, Switzerland, Mar. International Telecommunication Union, Geneva, Switzerland, Mar.
1993. 1993.
[24] O. Levin, "H.323 uniform resource locator (URL) scheme [24] O. Levin, "H.323 uniform resource locator (URL) scheme
registration," RFC 3508, Internet Engineering Task Force, Apr. 2003. registration," RFC 3508, Internet Engineering Task Force, Apr. 2003.
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
intellectual property 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; neither does it represent that it
has made any effort to identify any such rights. Information on the
IETF's procedures with respect to rights in standards-track and
standards-related documentation can be found in BCP-11. Copies of
claims of rights made available for publication 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 implementors or users of this specification can
be obtained from the IETF Secretariat.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights which may cover technology that may be required to practice
this standard. Please address the information to the IETF Executive
Director.
Full Copyright Statement Full Copyright Statement
Copyright (c) The Internet Society (2003). All Rights Reserved. Copyright (c) The Internet Society (2003). All Rights Reserved.
This document and translations of it may be copied and furnished to This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are kind, provided that the above copyright notice and this paragraph are
 End of changes. 

This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/