Subject: Re: [IPTEL] CPL features

From: Jonathan Lennox <[email-masked]>
Date: Wed, 16 Aug 2000 12:49:30 -0400 (EDT)

[My e-mail was down for five days...I'm replying based on the web archive,
so apologies for any infelicities in formatting and the loss of references
headers.]

On Tue, 15 Aug 2000, Jiri Kuthan wrote to [email-masked]:

> Checking the scripts by servers does not seem so helpful to me:
> 1) support for arbitrary headers accomplishes dealing with fields unknown
>    at the time of writing specification and implementation;
>    checking header fields if they are well-known beats this purpose;

> It's a trade-off between CPL's ability to adapt to new SIP extensions 
> and the built-in language ability to eliminate unwanted bugs. I personally 
> prefer the former given SIP development pace. Unwanted bugs may be still 
> prevented by tools used for generating CPL scripts.

I'd like to re-iterate Jonathan R.'s point that CPL is *not* just for SIP.
The spec is written with a lot of H.323 bindings in it, and I've also heard
reports of people using it for PSTN calls.

The information in the switches, therefore, doesn't correspond to SIP
headers.  Instead, it's a textual representation of information in the call
setup request.  This is often the *same* as how the information is
represented in the SIP header, because there's no point in being
gratuitously incompatible, but a major design requirement of CPL was to be
protocol-neutral in at least its core features.

If you want finer-grained control specifically targeted to SIP, SIP-CGI and
SIP Servlets are both available.  CPL was never intended to be the sole
answer to all of IP telephony service creation.

> 2) the rejection mechanism may be difficult if you use, for example,
>    FTP to upload the CPL scripts.

Clearly there always has to be *some* point when a server notices that a
script is invalid, it ought to have some way of reporting this failure in a
more clever way than sending a failure response back to the caller.  It
seems like good programming practice to notice this, if you can, earlier
than at the last minute, so the script owner can fix the problem before he
or she loses calls.  I'm not recommending some sort of active negotiation of
script capabilities.

-- 
Jonathan Lennox
[email-masked]

_______________________________________________
IPTEL mailing list
[email-masked]
http://lists.bell-labs.com/mailman/listinfo/iptel

---

From: Henning Schulzrinne <[email-masked]>
Date: Sun, 20 Aug 2000 18:03:54 -0400

There are two, I believe, reasonable ways to look at non-standard
information:

1) Italian-style ("what isn't illegal is allowed"): A server could
simply ignore the switch if it doesn't understand the
information/header. All scripts work, but the same call may be processed
differently. Also allows better functionality on some ("better")
servers. This has been pretty much the HTML approach, so that even a
Mosaic 1.0 browser can, in theory, render complex web pages, just
without a lot of formatting.

2) German-style ("what isn't allowed explicitly is verboten"): Server
rejects scripts that have unknown information/header switches. Opposite
trade-offs.

It is probably easier to switch later from German-style to Italian,
without syntax change. 

A different, but related discussion is how (or if) we want to handle
extensions in the future. I think SIP has shown that thinking about
extensions ahead of time is valuable. Should every new 'header' field,
for example, require rev'ing the version number of CPL?