A. An Algorithm for Resolving Time Switches
The following algorithm determines whether a given instant falls
within a repetition of a "time-switch" recurrence. If the pre-
processing described in Section 4.4.1 has been done, it operates in
constant time. Open-source Java code implementing this algorithm is
available at http://www.cs.columbia.edu/~lennox/Cal-Code/ on the
world wide web.
This algorithm is believed to be correct, but this section is non-
normative. Section 4.4, and RFC 2445 , are the definitive
definitions of recurrences.
1. Compute the time of the call, in the timezone of the time
2. If the call time is earlier than "dtstart", fail NOMATCH.
3. If the call time is less than "duration" after dtstart, succeed
4. Determine the smallest unit specified in a "byxxx" rule or by
the "freq." Call this the Minimum Unit. Determine the
previous instant (before or equal to the call time) when all
the time units smaller than the minimum unit are the same as
those of "dtstart." If the minimum unit is a second, this time
is the same as the instant. If the minimum unit is a minute or
an hour, the minutes or the minutes and hours, respectively,
must be the same as "dtstart". For all other minimum units,
the time-of-day must be the same as "dtstart." If the minimum
unit is a week, the day-of-the-week must be the same as
"dtstart." If the minimum unit is a month, the day-of-the-
month must be the same as "dtstart." If the minimum unit is a
year, the month and day-of-month must both be the same as
"dtstart." (Note that this means it may be necessary to roll
back more than one minimum unit -- if the minimum unit is a
month, then some months do not have a 31st (or 30th or 29th)
day; if the minimum unit is a year, then some years do not have
a February 29th. In the Gregorian calendar, it is never
necessary to roll back more than two months if the minimum unit
is a month, or eight years if the minimum unit is a year.
Between 1904 and 2096, it is never necessary to roll back more
than four years -- the eight-year rollback can only occur when
the Gregorian calendar "skips" a leap year.
Call this instant the Candidate Start Time.
5. If the time between the candidate start time and the call time
is more than the duration, fail NOMATCH.
6. If the candidate start time is later than the "until" parameter
of the recurrence (or the virtual "until" computed off-line
from "count"), fail NOMATCH.
7. Call the unit of the "freq" parameter of the recurrence the
Frequency Unit. Determine the frequency unit enclosing the
Candidate Start Time, and that enclosing "dtstart". Calculate
the number of frequency units that have passed between these
two times. If this is not a multiple of the "interval"
parameter, fail NOMATCH.
8. For every "byxxx" rule, confirm that the candidate start time
matches one of the options specified by that "byxxx" rule. If
so, succeed MATCH.
9. Calculate a previous candidate start time. Repeat until the
difference between the candidate start time and the call time
is more than the duration. If no candidate start time has been
validated, fail NOMATCH.
B. Suggested Usage of CPL with H.323
This appendix gives a suggested usage of CPL with H.323 . Study
Group 16 of the ITU, which developed H.323, is proposing to work on
official CPL mappings for that protocol. This section is therefore
B.1. Usage of "address-switch" with H.323
Address switches are specified in Section 4.1. This section
specifies the mapping between H.323 messages and the fields and
subfields of address-switches.
For H.323, the "origin" address corresponds to the alias addresses in
the "sourceAddress" field of the "Setup-UUIE" user-user information
element, and to the Q.931  information element "Calling party
number." If both fields are present, or if multiple alias addresses
for "sourceAddress" are present, which one has priority is a matter
of local server policy; the server SHOULD use the same resolution as
it would use for routing decisions in this case. Similarly, the
"destination" address corresponds to the alias addresses of the
"destinationAddress" field, and to the Q.931 information element
"Called party number."
The "original-destination" address corresponds to the "Redirecting
number" Q.931 information element, if it is present; otherwise it is
the same as the "destination" address.
The mapping of H.323 addresses into subfields depends on the type of
the alias address. An additional subfield type, "alias-type", is
defined for H.323 servers, corresponding to the type of the address.
Possible values are "dialedDigits", "h323-ID", "url-ID",
"transportID", "email-ID", "partyNumber", "mobileUIM", and "Q.931IE".
If future versions of the H.323 specification define additional types
of alias addresses, those names MAY also be used.
In versions of H.323 prior to version 4, "dialedDigits" was known as
"e164". The two names SHOULD be treated as synonyms.
The value of the "address-type" subfield for H.323 messages is "h323"
unless the alias type is "url-ID" and the URL scheme is something
other than h323; in this case the address-type is the URL scheme, as
specified in Section 4.1.1 for SIP.
An H.323-aware CPL server SHOULD map the address subfields from the
primary alias used for routing. It MAY also map subfields from other
aliases, if subfields in the primary address are not present.
The following mappings are used for H.323 alias types:
dialedDigits, partyNumber, mobileUIM, and Q.931IE: the "tel" and
"user" subfields are the string of digits, as is the
"entire-address" form. The "host" and "port" subfields are
url-ID: the same mappings are used as for SIP, in Section 4.1.1.
h323-ID: the "user" field is the string of characters, as is the
"entire-address" form. All other subfields are not present.
email-ID: the "user" and "host" subfields are set to the
corresponding parts of the e-mail address. The "port" and
"tel" subfields are not present. The "entire-address" form
corresponds to the entire e-mail address.
transportID: if the TransportAddress is of type "ipAddress,"
"ipSourceRoute," or "ip6Address," the "host" subfield is set
to the "ip" element of the sequence, translated into the
standard IPv4 or IPv6 textual representation, and the "port"
subfield is set to the "port" element of the sequence
represented in decimal. The "tel" and "user" fields are not
present. The "entire-address" form is not defined. The
representation and mapping of transport addresses is not
defined for non-IP addresses.
H.323  defines an "h323" URI scheme. This appendix defines a
mapping for these URIs onto the CPL "address-switch" subfields, as
given in Section 4.1. This definition is also available as RFC 3508
, which is an excerpt from the H.323 specification.
For h323 URIs, the "user", "host", and "port" subfields are set to
the corresponding parts of the H.323 URL. The "tel" subfield is not
present. The "entire-address" form corresponds to the entire URI.
This mapping MAY be used both for h323 URIs in an h323 "url-ID"
address alias, and for h323 URIs in SIP messages.
B.2. Usage of "string-switch" with H.323
For H.323, the "string-switch" node (see Section 4.2) is used as
follows. The field "display" corresponds to the Q.931 information
element of the same name, copied verbatim. The fields "subject",
"organization", and "user-agent" are not used and are never present.
The "display" IE is conventionally used for Caller-ID purposes, so
arguably it should be mapped to the "display" subfield of an
"address-match" with the field "originator". However, since a) it
is a message-level information element, not an address-level one,
and b) the Q.931 specification  says only that "[t]he purpose
of the Display information element is to supply display
information that may be displayed by the user," it seems to be
more appropriate to allow it to be matched in a "string-switch"
B.3. Usage of "language-switch" with H.323
The language-ranges for the "language-switch" switch are obtained
from the H.323 UUIE "language". The switch is not-present if the
initial message did not contain this UUIE.
B.4. Usage of "priority-switch" with H.323
All H.323 messages are considered to have priority "normal" for the
purpose of a priority switch (see Section 4.5).
B.5. Usage of "location" with H.323
Locations in explicit location nodes (Section 5.1) are specified as
URLs. Therefore, all locations added in this manner are interpreted
as being of alias type "url-ID" in H.323.
Specifications of other H.323 address alias types will require a CPL
extension (see Section 11).
B.6. Usage of "lookup" with H.323
For location lookup nodes (Section 5.2), the "registration" lookup
source corresponds to the locations registered with the server using
B.7. Usage of "remove-location" with H.323
Location removal nodes (Section 5.3) remove addresses with the alias
type "url-ID" using verbatim string matching on the URLs. If a "tel"
URL is specified as the location, matching addresses (ignoring visual
separators) with the alias types "dialedDigits" ("e164"),
"partyNumber", "mobileUIM", or "Q.931IE" are also removed. No
mechanism is provided to remove other alias types.
C. The XML Schema for CPL
This section includes a full XML Schema describing the XML syntax of
CPL. Every script submitted to a CPL server SHOULD comply with this
XML Schema. When parsing scripts comply with the CPL DTD in earlier
documents, the DOCTYPE lines in the scripts should be ignored. Note
that compliance with this schema is not a sufficient condition for
correctness of a CPL script, as many of the conditions described in
this specification are not expressible in schema syntax. Figure 31
shows the structure of the schema. 'incoming' and 'outgoing' are
defined as the substitutionGroup of the 'toplevelaction'. All the
switches are defined as the substitutionGroup of the 'switch'
element. All the actions are defined as the substitutionGroup of the
minute. Valid values are 0 to 59.</xs:documentation>
<xs:attribute name="byminute" type="xs:string" use="optional">
<xs:documentation>Comma-separated list of minutes within an
hour. Valid values are 0 to 59.</xs:documentation>
<xs:attribute name="byhour" type="xs:string" use="optional">
<xs:documentation>Comma-separated list of hours of the day.
Valid values are 0 to 23.</xs:documentation>
<xs:attribute name="byday" type="xs:string" use="optional">
<xs:documentation>Comma-separated list of days of the week.
Valid values are "MO", "TU", "WE", "TH", "FR", "SA" and
"SU". These values are not case-sensitive. Each can be
preceded by a positive (+n) or negative (-n)
<xs:attribute name="bymonthday" type="xs:string" use="optional">
<xs:documentation>Comma-separated list of days of the month.
Valid values are 1 to 31 or -31 to
<xs:attribute name="byyearday" type="xs:string" use="optional">
<xs:documentation>Comma-separated list of days of the year.
Valid values are 1 to 366 or -366 to
<xs:attribute name="byweekno" type="xs:string" use="optional">
<xs:documentation>Comma-separated list of ordinals specifying
weeks of the year. Valid values are 1 to 53 or -53 to
<xs:attribute name="bymonth" type="xs:string" use="optional">
<xs:documentation>Comma-separated list of months of the year.
<xs:element name="ancillary" type="AncillaryType" minOccurs="0"
<xs:element name="subaction" type="SubactionType" minOccurs="0"
<xs:element ref="toplevelaction" minOccurs="0"
<xs:documentation>Any toplevel action MUST NOT appear more
<xs:element name="cpl" type="CPLType"/>
 Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A.,
Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP:
Session Initiation Protocol", RFC 3261, June 2002.
 Bray, T., Paoli, J., Sperberg-McQueen, C. M., Maler, E., and F.
Yergeau, "Extensible Markup Language (XML) 1.0 (Third Edition)",
W3C Recommendation REC-xml-20040204, World Wide Web Consortium
(W3C), February 2004. Available at http://www.w3.org/XML/.
 Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
 Hinden, R. and S. Deering, "Internet Protocol Version 6 (IPv6)
Addressing Architecture", RFC 3513, April 2003.
 Davis, M. F. and M. Duerst, "Unicode Normalization Forms",
Unicode Standard Annex #15, Unicode Consortium, April 2003.
Revision 23; part of Unicode 4.0.0. Available at
 Davis, M. F., "Case Mappings", Unicode Standard Annex #21,
Unicode Consortium, March 2001. Revision 5; part of Unicode
3.2.0. Available at
 Alvestrand, H., "Tags for the Identification of Languages", BCP
47, RFC 3066, January 2001.
 Dawson, F. and D. Stenerson, "Internet Calendaring and
Scheduling Core Object Specification (iCalendar)", RFC 2445,
 Eggert, P., "Sources for Time Zone and Daylight Saving Time
Data". Available at http://www.twinsun.com/tz/tz-link.htm.
 Mealling, M. and R. Daniel, "URI Resolution Services Necessary
for URN Resolution", RFC 2483, January 1999.
 Bray, T., Hollander, D., and A. Layman, "Namespaces in XML", W3C
Recommendation REC-xml-names-19990114, World Wide Web Consortium
(W3C), January 1999. Available at http://www.w3.org/TR/REC-
 Moats, R., "URN Syntax", RFC 2141, May 1997.
 Moats, R., "A URN Namespace for IETF Documents", RFC 2648,
 Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, January
 Murata, M., St.Laurent, S., and D. Kohn, "XML Media Types", RFC
3023, January 2001.
 International Telecommunication Union, "Packet-based multimedia
communication systems", Recommendation H.323, Telecommunication
Standardization Sector of ITU, Geneva, Switzerland, July 2003.
 Lennox, J. and H. Schulzrinne, "Call Processing Language
Framework and Requirements", RFC 2824, May 2000.
 Raggett, D., Le Hors, A., and I. Jacobs, "HTML 4.01
Specification", W3C Recommendation REC-html401-19991224, World
Wide Web Consortium (W3C), December 1999. Available at
 ISO (International Organization for Standardization),
"Information processing -- Text and office systems -- Standard
Generalized Markup Language (SGML)", ISO Standard ISO
8879:1986(E), International Organization for Standardization,
Geneva, Switzerland, October 1986.
 ISO (International Organization for Standardization), "Data
elements and interchange formats -- Information interchange --
Representation of dates and times", ISO Standard ISO
8601:2000(E), International Organization for Standardization,
Geneva, Switzerland, December 2000.
 DeRose, S., Maler, E., Orchard, D., and B. Trafford, "XML
Linking Language (XLink) Version 1.0", W3C Recommendation REC-
xlink-20010627, World Wide Web Consortium (W3C), June 2001.
Available at http://www.w3.org/TR/xlink/.
 Showalter, T., "Sieve: A Mail Filtering Language", RFC 3028,
 International Telecommunication Union, "Digital Subscriber
Signalling System No. 1 (DSS 1) - ISDN user-network interface
layer 3 specification for basic call control", Recommendation
Q.931, International Telecommunication Union, Geneva,
Switzerland, March 1993.
 Levin, O., "H.323 Uniform Resource Locator (URL) Scheme
Registration", RFC 3508, April 2003.
Dept. of Computer Science
1214 Amsterdam Avenue, MC 0401
New York, NY 10027
Dept. of Computer Science
1214 Amsterdam Avenue, MC 0401
New York, NY 10027
Dept. of Computer Science
1214 Amsterdam Avenue, MC 0401
New York, NY 10027
Full Copyright Statement
Copyright (C) The Internet Society (2004).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the IETF's procedures with respect to rights in IETF Documents can
be found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at ietf-
Funding for the RFC Editor function is currently provided by the