\documentclass[11pt]{article}
\usepackage{times}
\usepackage{graphics}
\usepackage{i-d}
\usepackage{tight}
\usepackage{txtpsfig}
\usepackage{verbatimfiles}

\newcommand{\header}[1]{{\sf{}#1}}
\newcommand{\motivation}[1]{{\footnotesize\begin{quotation}#1\end{quotation}}}

\newcommand{\MUST}{\textsc{must}}
\newcommand{\MUSTNOT}{\textsc{must not}}
\newcommand{\REQUIRED}{\textsc{required}}
\newcommand{\SHALL}{\textsc{shall}}
\newcommand{\SHALLNOT}{\textsc{shall not}}
\newcommand{\SHOULD}{\textsc{should}}
\newcommand{\SHOULDNOT}{\textsc{should not}}
\newcommand{\MAY}{\textsc{may}}
\newcommand{\OPTIONAL}{\textsc{optional}}
\newcommand{\RECOMMENDED}{\textsc{recommended}}
\newcommand{\NOTRECOMMENDED}{\textsc{not recommended}}

\newcommand{\defexample}[2]{
\begin{description}
\item[\tt{}#1]\ \\
#2
\end{description}
}

\title{CPL: A Language for User Control of Internet Telephony Services}
\author{Lennox/Schulzrinne}
\shorttitle{CPL}
\filename{ietf-iptel-cpl-00}
\wg{IPTEL WG}
\address{Columbia University}
\pubdate{\today}
\expires{September 1999}

\begin{document}
\maketitle

\begin{abstract}

The Call Processing Language (CPL) is a language that can be used to
describe and control Internet telephony services.  It is designed to be
implementable on either network servers or user agent servers.  It is meant
to be simple, extensible, easily edited by graphical clients, and
independent of operating system or signalling protocol.  It is suitable for
running on a server where users may not be allowed to execute arbitrary
programs, as it has no variables, loops, or ability to run external
programs.

This document is a product of the IP Telephony (IPTEL) working group of the
Internet Engineering Task Force.  Comments are solicited and should be
addressed to the working group's mailing list at
iptel@lists.research.bell-labs.com and/or the authors.
\end{abstract}

\tableofcontents

\section{Introduction}

The Call Processing Language (CPL) is a language that can be used to
describe and control Internet telephony services.  It is not tied to any
particular signalling architecture or protocol; it is anticipated that it
will be used with both SIP \cite{draft-ietf-mmusic-sip} and H.323
\cite{h.323}.

The CPL is powerful enough to describe a large number of services and
features, but it is limited in power so that it can run safely in Internet
telephony servers.  The intention is to make it impossible for users to do
anything more complex (and dangerous) than describing Internet telephony
services.  The language is not Turing-complete, and provides no way to write
a loop or a function.

The CPL is also designed to be easily created and edited by graphical tools.
It is based on XML \cite{xml}, so parsing it is easy and many parsers for it
are publicly available.  The structure of the language maps closely to its
behavior, so an editor can understand any valid script, even ones written by
hand.  The language is also designed so that a server can easily confirm
scripts' validity at the time they are delivered to it, rather that
discovering them while a call is being processed.

Implementations of the CPL are expected to take place both in Internet
telephony servers and in advanced clients; both can usefully process and
direct users' calls.  In the former case, a mechanism will be needed to
transport scripts between clients and servers; this document does not
describe such a mechanism, but related documents will.

\subsection{Conventions Of This Document}

In this document, the key words ``{\MUST}'', ``{\MUSTNOT}'',
``{\REQUIRED}'', ``{\SHALL}'', ``{\SHALLNOT}'', ``{\SHOULD}'',
``{\SHOULDNOT}'', ``{\RECOMMENDED}'', ``{\MAY}'', and ``{\OPTIONAL}''
are to be interpreted as described in RFC 2119 \cite{rfc2119} and
indicate requirement levels for compliant CPL implementations.

In examples, non-XML strings such as {\tt{}-action1-}, {\tt{}-action2-}, and
so forth, are sometimes used.  These represent further parts of the script
which are not relevant to the example in question.

\motivation{Some paragraphs are indented, like this; they give motivations
of design choices, or questions for future discussion in the development of
the CPL, and are not essential to the specification of the language.}

\section{Structure of CPL scripts}

\subsection{Abstract structure}
\label{subsec:abstract}

Abstractly, a CPL script is described by a collection of nodes, which
describe actions that can be performed or choices which can be made.  A node
may have several parameters, which specify the precise behavior of the node;
they usually also have outputs, which depend on the result of the condition or
action.

For a graphical representation of a CPL script, see figure~\ref{fig:sample}.
Nodes and outputs can be thought of informally as boxes and arrows; the CPL
is designed so that it can be conveniently edited graphically using this
representation.  Nodes are arranged in a directed acyclic graph, starting at
a single root node; outputs of nodes are connected to additional nodes.
When a CPL script is run, the action or condition described by the root node
is performed; based on the result of that node, the server follows one of
the node's outputs, and that action or condition is performed; this process
continues until a node with no specified outputs is reached.  Because the
graph is acyclic, this will occur after a bounded and predictable number of
nodes are visited.

If an output to a node is not specified, it indicates that the CPL server
should perform a node- or protocol-specific action.  Some nodes have
specific default actions associated with them; for others, the default
action is implicit in the underlying signalling protocol, or can be
configured by the administrator of the server.

\txtpsfigsize{\textwidth}{!}{sample}{Sample CPL Script: Graphical Version}

\subsection{XML Structure}

Syntactically, CPL scripts are represented by XML documents.  XML is
thoroughly specified by \cite{xml}, and implementors of this specification
should be familiar with that document, but as a brief overview, XML consists
of a hierarchical structure of tags; each tag can have a number of
attributes.  It is visually and structurally very similar to HTML
\cite{html4}, as both languages are simplifications of the earlier and larger
standard SGML \cite{sgml}.

See figure~\ref{fig:xmlsample} for the XML document corresponding to the
graphical representation of a CPL script in figure~\ref{fig:sample}.  Both
nodes and outputs in the CPL are represented by XML tags; parameters are
represented by XML tag attributes.  Typically, node tags contain output
tags, and vice-versa (with one exception; see section
\ref{subsec:location}).

The connection between the output of a node and another node is represented
by enclosing the tag representing the pointed-to node inside the tag for the
outer node's output.  Convergence (several outputs pointing to a single
node) is represented by links, discussed further in section~\ref{sec:links}.
The top-level node is enclosed in the special tag \header{call}; this is
therefore the outermost tag of the XML.

A complete Document Type Declaration for the CPL is provided in
Appendix~\ref{sec:dtd}.  The remainder of the main sections of this document
describe the semantics of the CPL; for its syntax, please see the appendix.

\begin{figure}
\verbatimfile{xmlsample.txt}
\caption{Sample CPL Script: XML Version}
\label{fig:xmlsample}
\end{figure}

\section{Switches}

Switches represent choices the CPL script can make, based on either
attributes of the original call request or items independent of the call.

All switches are arranged as a list of conditions that can match a variable,
each with one output pointing to the next node to execute if that condition
is matched.  The conditions specified are tried in the order they are
presented in the script; the output corresponding to the first node to match
is taken.  Switches also have an optional \header{otherwise} output,
following all the other outputs, that matches if no previous node matched.
If a switch does not have an \header{otherwise} output, and no condition
matched, the server should take a default action, just as for any other
un-attached node output, as discussed in section~\ref{subsec:abstract}.

The variable to match is specified in the initial switch tag, as a
\header{field} parameter.  What variables are legal depends on which switch
type is specified; some variables are optional, and CPL servers {\MAY}
define additional variables for each switch type.  Because some variables
may not be supported by a server, CPL servers {\SHOULD} verify, at the time
a script is submitted, that they support all the variables specified in the
script.

\subsection{String Switch}

String-switch is a condition which allows string matching on a string
variable.  The node tag is named \header{string-switch}, and takes one
argument, \header{field}, as discussed above.  The output tags are named
\header{string}, and take one mandatory and one optional argument.  The
mandatory argument's name is one of \header{is}, \header{contains}, or
\header{matches}, indicating exact string match, substring match, or
glob match of the variable respectively.

The optional argument of \header{string} output tags is \header{comparator},
which allows for internationalization of string matching.  Strings to be
matched are always considered as strings of UTF-8 characters. CPL servers
{\MUST} support the two comparators \header{i;octet}, indicating literal
comparison of UTF-8 octets, and \header{i;ascii-casemap}, which indicates
that alphabetic characters in the US-ASCII range should have their upper and
lower cases compared the same.  If no comparitor is specified,
\header{i;ascii-casemap} is assumed.  Comparators are defined by ACAP
\cite{rfc2244}; for more information, see that specification.  CPL servers
{\SHOULD} verify at script submission time that all requested comparators
are supported by the server.

\motivation{The naming scheme of comparators is as defined by ACAP; the
motivation of the ``i;'' prefix of the comparators is unclear, but it seems
to be some sort of namespace for future use.}

\motivation{Question: should comparator be an attribute of the whole
string-switch as opposed to an attribute of each comparison?  There are
arguments for either behavior.}

All CPL servers {\MUST} define the fields \header{to} and \header{from} for
string matching, containing URIs referring to the called and calling
addresses, respectively.  CPL servers which run on SIP {\SHOULD} also define
\header{request-uri}, \header{subject}, \header{organization},
\header{priority}, containing the contents of the equivalent SIP headers, if
present, and also \header{display-to}, and \header{display-from}, containing
the display names corresponding to the called and calling addresses.  CPL
servers which run on H.323 {\SHOULD} define XXX.

\motivation{Question: what are the appropriate string fields for H.323?}

In this example, action1 is performed if the URL representation of the
caller's address exactly matches ``sip:lennox@cs.columbia.edu,'' action2 is
performed for any string which matches any user at any host in the
cs.columbia.edu domain, and action3 is taken in all other cases.

\begin{verbatim}
<string-switch field="from">
  <string is="sip:lennox@cs.columbia.edu">
     -action1-
  </string>
  <string matches="*@*cs.columbia.edu">
     -action2-
  </string>
  <otherwise>
     -action3-
  </otherwise>
</string-match>
\end{verbatim}

\subsection{Time Switch}

Time-switch is a condition which allows matching on the time and/or date the
triggering call was placed.  Times are matched in the server's time zone.
The node tag is named \header{time-switch}, and takes no arguments; the
output tags are named \header{time}.

\motivation{Note: while it would be nice to allow clients to specify their
own time zone, there doesn't currently appear to be any standard registry of
time zone names, and we don't want to have to define one just for the CPL.
Leveraging off of the iCalendar standard \cite{rfc2445} would be nice, but
their time zone specification seems excessively heavyweight --- it defines
time zone rules explicitly (and very verbosely) in its own syntax.  Just
specifying time zones as UTC offsets would be possible, but this doesn't
cover daylight-savings time rules.  Thus, we currently ignore the problem.}

The \header{time} outputs can take the following optional arguments:
\header{year}, \header{month}, \header{date}, \header{day}, and
\header{timeofday}.  Each argument is syntactically expressed as a list of
numeric ranges.  Ranges are delimited as value-value; lists elements are
separated by commas.  Months are specified in the range 1-12; date as 1-31,
day as 0-6 (where 0 is Sunday), and times of day as 24-hour times in the
range 0000-2359; years are unlimited in range, though only positive values
are allowed.

An output node matches if the time the triggering call was placed falls
within one of the ranges in all of the specified arguments.

The following examples show sample \header{time} nodes, and descriptions of
the corresponding time periods they indicate:

\defexample{<time month="12" date="25" year="1999">}
	{December 25th, 1999, all day}

\defexample{<time month="5" date="4">}
	{May 4th, every year, all day}

\defexample{<time day="1-5" timeofday="0900-1700">}
	{9 AM -- 5 PM, Monday through Friday, every week}

\defexample{<time timeofday="1310-1425,1440-1555,1610-1725" day="2,4">}
	{1:10 -- 2:25 PM, 2:40 -- 3:55 PM, and 4:10 -- 5:25 PM,
	Tuesdays and Thursdays, every week}

\defexample{<time date="1-7" day="1">}
	{The first Monday of every month, all day}

If more complicated time ranges need to be specified, they {\SHOULD} be
broken down into component ranges specifiable in this syntax, and their
outputs connected the outputs to the same subsequent node with links (see
section~\ref{sec:links}).

\subsection{Other Switches}

\motivation{Question: how should we switch based on media?  We need a syntax
for this.  We could just switch on media type as a MIME type; the problem is
that you may have several media types defined.  Other important attributes
of media include required bandwidth (numeric) and source address (IPv4
address, usually, but IPv6 in the future) --- do we need switch types for
these?}

\section{Locations}

A number of CPL actions (defined in section~\ref{sec:actions}) need to have
locations specified.  An executing CPL always has some set of locations
specified; CPLs use location nodes to add or clear locations from the set.

By default, location nodes add to the current set of locations.
Alternately, they can re-initialize the set, clearing it before adding
additional nodes.  This is specified with the argument \header{merge}, which
can take two possible values, \header{merge} and \header{clear}.  Its
default value is \header{merge}.

\subsection{Basic Location}
\label{subsec:location}

Basic location nodes (which have the tag name \header{location} specify a
location literally, as a URL.  They take a single argument, \header{url};
the desired location is given as an argument.  Only one location may be
specified per location node; multiple locations may be specified by
cascading these nodes.

Basic location nodes have only one possible output, since there is no way
that they can fail.  (If a basic location node specifies a location which
isn't supported by the underlying signalling protocol, the script server
{\SHOULD} detect this and report it to the user at the time the script is
submitted.)  Therefore, its XML representation does not have explicit output
nodes; the {\tt{}<location>} tag directly contains another node tag.

\subsection{Location Lookup}

Locations can also be looked up through external means, through the use of
the \header{lookup} tag.  The location to look up the result can be
specified either as a url, or as another source.  External URLs, are
specified with the attribute \header{url}, and should refer to an external
source which returns the {\tt{}application/url} media type.  Other sources
are specified with the attribute \header{source}.  The only source currently
defined is \header{registration}, which specifies all the locations
currently registered with the server, using SIP \header{REGISTER} or H.323
\header{RAS} messages.  A lookup tag {\MUST} specify exactly one of
\header{url} or \header{source}.

Lookup also has an optional attribute, \header{timeout}, which specifies the
time in seconds the script is willing to wait for the lookup to be
performed.  Lookup has three outputs: \header{success}, \header{notfound},
and \header{failure}.  Notfound is taken if the lookup process succeeded but
did not find any locations; failure is taken if the lookup failed for some
reason, including that specified timeout was exceeded.  If failure is not
specified, the action corresponding to notfound is taken; if notfound is not
specified, the success output is taken, but the current location set is not
modified.  The success output must be given.

Clients {\SHOULD} specify the three outputs \header{success},
\header{notfound}, and \header{failure} in that order, so their script
complies with the DTD given in Appendix~\ref{sec:dtd}, but servers {\SHOULD}
accept them in any order.

\section{Signalling Actions}
\label{sec:actions}

Signalling action nodes cause signalling events in the underlying signalling
protocol.

\subsection{Proxy}

Proxy causes the triggering call to be forwarded on to the currently
specified set of locations.  The server chooses the ``best'' response to the
call attempt, as defined by the protocol or its configuration rules.  If the
call attempt was successful, CPL execution terminates; otherwise, one of the
three outputs \header{busy}, \header{noanswer}, or \header{failure} is
taken.

\motivation{Note: future extension of the CPL to allow in-call or
end-of-call actions will require success outputs to be added as well.}

\motivation{Question: What other outputs are needed?  Redirect?  More
varieties of failure?}

If no locations are specified at the time the proxy command is executed, the 
server {\SHOULD} attempt to proxy the call to its standard set of addresses
for the user, or inform the caller that the caller is unavailable.

Proxy has one argument: \header{timeout}, which specifies the time, in
seconds, to wait for the call to be completed or rejected, after which time
the call attempt is terminated and the \header{noanswer} branch is taken.

\motivation{Question: Do we want to be able to specify timeouts in other
units, notably ``number of rings''?}

\subsection{Redirect}

Redirect causes the server to direct the calling party to attempt to place
its call to the currently specified set of locations.  This immediately
terminates execution of the CPL script, so this node has no outputs.  This
node also has no arguments other than the standard Link ID target (see
section~\ref{sec:links}).

\subsection{Response}

Response causes the server to reject the call attempt.  This immediately
terminates execution of the CPL script, so this node has no outputs.

This node has two arguments in addition to the standard Link ID (see
section~\ref{sec:links}): \header{status} and \header{reason}.  The
\header{status} argument is required, and can take one of the values
\header{busy}, \header{notfound}, \header{reject}, and \header{error}.
Servers which implement SIP {\MAY} also allow a numeric argument here
corresponding to a SIP status in the 4xx, 5xx, or 6xx range, but scripts
{\SHOULDNOT} use them if they wish to be portable.

The \header{reason} argument optionally allows the script to specify a
reason for the rejection.  CPL servers {\MAY} ignore the reason, but ones
that implement SIP {\SHOULD} send them in the SIP reason phrase.

The CPL does not define any way to send intermediate responses to call
attempts.  Servers {\SHOULD} send them automatically, as appropriate.

\motivation{Note: we need more named statuses.}

\motivation{Question: Success and redirection are also responses.  Should
this node be called ``failure'' or ``reject'' instead?}

\section{Other Actions}
\label{sec:otheractions}

In addition to the signalling actions, the CPL defines several actions which
do not affect the telephony signalling protocol.

\subsection{Notify}

The Notify node causes the server to notify a user of the status of the CPL
script through some non-telephony means; for instance, sending electronic
mail, or delivering an instant message.  It takes two arguments: a required
URL indicating the means and address to contact (attribute \header{url}),
and optionally a comment to be included in that message (attribute
\header{comment}).  The server sends the message containing the content to
the given url; it {\SHOULD} also include other status information about the
state of the call and the CPL script at the time of the notification.
Servers {\SHOULD} check the specified address at script submission time to
ensure that they understand the specified URL scheme.

This node has two outputs, \header{success} and \header{failure}.  The
success branch is mandatory; if no failure branch is specified, the success
branch is taken.  The outputs {\SHOULD} be specified in the order given.

\motivation{Question: is this too general?  Notification is a very broad
concept.  Would simply having a ``Mailto'' tag be cleaner?}

\subsection{Log}

The Log node causes the server to log information about the call to
non-volatile storage.  It takes two arguments, both optional: \header{name},
which specifies the name of the log, and \header{comment}, which gives a
comment about the information being logged.  Servers {\SHOULD} also include
other information in the log, such as the time of the logged event,
information that triggered the call to be logged, and so forth.  Logs are
specific to the owner of the script which log event.  This specification
does not define how users may retrieve their logs from the server.

This node has two outputs, \header{success} and \header{failure}.  The
success branch is mandatory; if no failure branch is specified, the success
branch is taken.  The outputs {\SHOULD} be specified in the order given.

\section{Links}
\label{sec:links}

XML syntax defines a tree.  Because the general structure of the CPL is
instead intended to be a directed acyclic graph, we provide the
\header{link} structure to allow several node outputs to connect to a single
node.

Every XML tag which represents a node has an optional argument \header{id},
which can be any XML id.  (The \header{id} attribute is a standard XML
attribute, defined in section 3.3.1 of the XML specification.)  Any output
which normally contains a node can, instead, contain a \header{link} tag
with a \header{ref} attribute specifying the ID of some other node.

Every link ref {\MUST} refer to a link ID specified in the same CPL script.
No external links are permitted.

\motivation{If any subsequent version ever defines external linkages, it
will use a different tag, perhaps XLINK \cite{xlink}.}

When the CPL server initially processes the script, it {\MUST} verify that
no link refers to a node that is its parent in the tree; i.e., it {\MUST}
verify that the directed graph created by the tree and the links is acyclic.
If it is not, the server {\SHOULD} treat this error in the same manner as
any other syntax error in a script.  (This verification is algorithmically
simply a matter of verifying that a depth-first search of the directed graph
contains no back edges; see, for instance, \cite{Corm90:Introduction}, Lemma
23.10.  It can typically be done simultaneously with the resolution of
links.)

\motivation{If cycles were allowed in the graph, it would introduce the
possibility of non-terminating CPL scripts, a possibility our requirements
specifically excluded.}

CPL servers {\MAY} use link IDs to identify nodes for other purposes, for
instance to report errors or to provide real-time debugging or flow
information.  Thus, scripts {\SHOULD} provide IDs for every node for which
they are interested in such information, even if no link connects to that
node.

\section{Examples}

\subsection{Example: Call Redirect Unconditional}

The script in figure~\ref{fig:cfu} is a simple script which redirects all
calls to a single fixed location.

\begin{figure}[h]
\verbatimfile{cfu.txt}
\caption{Example Script: Call Redirect Unconditional}
\label{fig:cfu}
\end{figure}

\subsection{Example: Call Forward Busy/No Answer}

The script in figure~\ref{fig:cfbna} illustrates some more complex
behavior.  We see an initial proxy attempt to one address, with further
actions if that fails.  We also see how several outputs can point to the
same node, through the use of the link tag.

\begin{figure}[htbp]
\verbatimfile{cfbna.txt}
\caption{Example Script: Call Forward Busy/No Answer}
\label{fig:cfbna}
\end{figure}

\subsection{Example: Call Screening}

The script in figure~\ref{fig:cs} illustrates string switches and call
rejection, in the form of a call screening script.  Note also that because
the string-switch lacks an \header{otherwise} clause, if the initial pattern
did not match, the script does not define any action.  The server therefore
proceeds with its default action, which would presumably be to contact the
user.

\begin{figure}[htbp]
\verbatimfile{cs.txt}
\caption{Example Script: Call Screening}
\label{fig:cs}
\end{figure}

\subsection{Example: Time-of-day Routing}

Figure~\ref{fig:tdr} illustrates time-based conditions.

\begin{figure}[htbp]
\verbatimfile{tdr.txt}
\caption{Example Script: Time-of-day Routing}
\label{fig:tdr}
\end{figure}

\subsection{Example: Non-call Actions}

Figure~\ref{fig:nca} illustrates non-call actions; in particular, alerting a
user by electronic mail if the lookup server failed.  The primary reason for
the Notify node is to allow this sort of out-of-band notification of error
conditions, as the user might otherwise be unaware of any problem.

\begin{figure}[htbp]
\verbatimfile{nca.txt}
\caption{Example Script: Non-call Actions}
\label{fig:nca}
\end{figure}

\subsection{Example: A Complex Example}

Finally, figure~\ref{fig:ce} 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 celphone, and all other calls are directed to voicemail.

\begin{figure}[htbp]
\verbatimfile{ce.txt}
\caption{Example Script: A Complex Example}
\label{fig:ce}
\end{figure}

\clearpage

\section{Security Considerations}

The 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 actions 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 actions are permitted.

\section{Acknowledgments}

We would like to thank Tom La~Porta and Jonathan Rosenberg for their
contributions and suggestions.

We drew a good deal of inspiration, notably the language's lack of
Turing-completeness and the syntax of string matching, from the
specification of Sieve \cite{draft-showalter-sieve}, a language for user
filtering of electronic mail messages.

\appendix

\section{The XML DTD for CPL}
\label{sec:dtd}

This section includes a full DTD describing the XML syntax of the CPL.
Every script submitted to a CPL server {\SHOULD} comply with this DTD;
however, CPL servers {\SHOULD} allow minor variations from it, particularly
in the ordering of output branches of nodes.  Note that compliance with this
DTD is not a sufficient condition for correctness of a CPL script, as
many of the conditions described above are not expressible in DTD syntax.

\verbatimfile{cpl.dtd}

\section{Authors' Addresses}

\begin{flushleft}
Jonathan Lennox\\
Dept. of Computer Science\\
Columbia University\\
1214 Amsterdam Avenue, MC 0401\\
New York, NY 10027\\
USA\\
electronic mail:  {\sf{}lennox@cs.columbia.edu}
\end{flushleft}

\begin{flushleft}
Henning Schulzrinne\\
Dept. of Computer Science\\
Columbia University\\
1214 Amsterdam Avenue, MC 0401\\
New York, NY 10027\\
USA\\
electronic mail:  {\sf{}schulzrinne@cs.columbia.edu}
\end{flushleft}

\bibliographystyle{ieeetr}
\begin{sloppy}
\bibliography{itu,i-d,rfc,net90,net94,local}
\end{sloppy}

\input{copyright}

\end{document}
