Subject: Few comments on requirements for CPL

From: Claudio Catania <[email-masked]>
Date: Fri, 09 Oct 1998 12:06:48 +0100

Hello,

From the minutes of the last IETF meeting, I got the impression that CPL
was a hot topic but, due to lack of time,  there had been several
unanswered questions about the slide set that J.Lennox presented.

I am struggling to understand what people in the mailing list think
about the requirements and what the status of this activity is.

 Recently I browsed through my Iptel archive and found  very few
comments about the CPL requirements draft.

Several questions came to my mind, I will try to summarize some of them
here, hoping that someone could help expanding on them.

1)
One of the things that could be achieved by CPL is the definition of a
controlled environment to create services on a "network device". This
seems to be very similar to the approach taken by IN community when they
tried to define SCEs for IN components.
*Does anyone have an opinion on how CPL could be related to those
efforts?

2)
I think that, after having spent several years trying to define good
controlled service creation environments for basic reliable services,
the IN community is struggling to enhance their simple model to add
distribution, flexibility and efficient
communication between network elements. Services for VoIP may have
completely different requirements but, at the end of the day,  we are
talking about server based call processing languages, therefore there
may be  a lot of similarities.
*Is CPL in a better position to address the issue of combining
flexibility with controlled environment for service creation?

3)
My understanding is that CPL proposes to run up to four different
scripts every time a service  is invoked (user and administrator scripts
for both originating  and destination party).  VoIP client and server
providers will have to ensure compatibility between them all. Now it is
very likely that the former will try to sell their own administrative
tools to configure and remote administer their clients while the latter
will probably be reluctant  to share a common service environment (I
could be wrong, but I think that this is exactly what happened to  IN
SCEs and service languages).
*Who would really benefit from a standardized way of writing services in
CPL?
*How will VoIP client and server providers deal with potential conflicts
between scripts running on different environment? (I guess that the
draft identifies these problems and calls them server to server
interactions;  I could not figure out how the problem is solved.)

4)
According to the draft, CPL can be implemented in several languages (see
the requirements), but I got the impression that the adopted one will be
XML.
*Why? Is there a compelling reason for which XML should be used? Are the
reasons mentioned in the draft good enough?
*What is good in using XML for services?

5)
A service based on a call processing language have to be mainly stateful
and event driven (the draft mentioned a few non stateless service
scenarios)
*Why is a "non-expressively-complete scripting language" the best
solution for that?

6)
My understanding is that approaches based on a expressively-complete
languages (TAPI, old TSAPI...) successfully hide the call processing
coming from different signalling stacks. There had been several attempts
to standardize those solutions but no one reached global consensus. I
guess that this happened  mainly because vendors did not want to open
their platforms thus providing the aprropriate drivers for standardized
environments.
*If  CPL has the same requirements, will VoIP server vendors behave in a
different way and open up their APIs to CPL?

I apologize for such a long mail

Claudio Catania

--
----------------------------------------------------------
 Claudio Catania  Senior Research engineer
 mailto:[email-masked]    Hewlett-Packard Laboratories
 Phone: +44 117 922 8235
 Fax:   +44 117 922 8003     Filton Road, Stoke Gifford
 Telnet: 312 8235            Bristol (U.K.)  BS34 8QZ
----------------------------------------------------------

---------
This message came from the IETF IPTEL Working Group Mailing List.

---

From: Jonathan Rosenberg <[email-masked]>
Date: Fri, 23 Oct 1998 17:53:19 -0400

> comments about the CPL requirements draft.

Right now the group is "focusing" on getting the gateway location
framework document out. Most of the discussion has centered around this,
rather than the CPL stuff.

> *Does anyone have an opinion on how CPL could be related to those

I'm really not that familiar with the SCE's in IN components. My
understanding (and please correct if I'm mistaken) is that these are
interfaces and tools for linking together objects, events, and actions
to define services. They are used primarily by network administrators.
In my mind, the CPL is not meant to be a complete and fully specified
tool to define all possible services. I think the focus should be on a
language that exposes certain services to end users. This, as a result,
generates the requirements for safety, simplicity, and ease of use and
generation. This doesn't mean that a CPL couldn't be used by an
administrator to define new services, but that it is engineered to be
created by end users. This, I think, means it is not (nor should it be)
a complete environment for truly flexible service creation. It should
expose a limited and controlled set of options and features to an end
user, but no more.

However, we could certainly learn from the SCE efforts, and I would
encourage drafts/email on the subject.

> flexibility with controlled environment for service creation?

As I mention above, I don't think its meant to encompass the breadth
provided by IN SCE's, but I'd welcome discussion if people believe
otherwise.

> for both originating  and destination party).

No, there is no such limit. There may be many scripts which run. 

  VoIP client and server
> *Who would really benefit from a standardized way of writing services in

End users. These scripts would be standardized ways for end users to
"configure", in a limited sense, servers, and possibly clients. I do not
think that the CPL will be an effective tool for service providers to
configure servers, but they would be welcome to do so if it fits their
needs.

> interactions;  I could not figure out how the problem is solved.)

Could you clarify exactly which aspects of the problem didn't seem
resolved in the draft?

> *What is good in using XML for services?

The original idea was to possibly use something like Tcl. However, XML
has some compelling features. Safety is the main issue with the CPL -
since the focus is on generation by end users and execution in network
servers, the providers must be sure that the scripts will terminate, and
can't do malicious things. We also wanted to be able to make sure the
script was syntactically and semantically correct. XML is nice in this
regard - we can define a restricted set of keywords, and the script is
in a highly structured, easily parsable and verifiable format. Its
hardly a programming language at all - but I think thats what we want.
Its also easily extended with new keywords using standard XML
mechanisms.

XML has its drawbacks - its nested structure makes specification of some
services fairly ugly. Its structure also makes a lot of standard
programming constructs complex - but one can argue that this is a good
thing. Again, we're not looking for a full blown language/API here -
just a syntax an end user can upload to specify some basic services.

> *Why is a "non-expressively-complete scripting language" the best

Again, I think its related to the environment we're considering -
generation by end users.

> different way and open up their APIs to CPL?

I think the amount of "opening" we're talking about here is quite a bit
less than TAPI and TSAPI. There are definitely examples of where service
providers in the IP world have made network services available to end
users - CGI scripts, .forward files, both expose aspects of web and
email services to end users. Whether the CPL will be successful or not,
only time will tell.

-Jonathan R.

-- 
Jonathan D. Rosenberg                       Lucent Technologies
Member of Technical Staff                   101 Crawfords Corner Rd.
High Speed Networks Research                Holmdel, NJ 07733
FAX:   (732) 834-5379                       Rm. 4C-526
EMAIL: [email-masked]
URL: http://www.cs.columbia.edu/~jdrosen
---------
This message came from the IETF IPTEL Working Group Mailing List.

---

From: "Karen Goettler" <[email-masked]>
Date: Thu, 29 Oct 1998 17:37:56 -0700

I teach an 'IN Networks and Services' class at a local university and have
been wondering, since you are talking about VoIP Services and the VoIP CLP,
'How are VoIP services triggered?'.

It seems like the services should be triggered as part of the CPL, but does
the CPL for VoIP have defined states where services could be triggered?
Also, where will the CPL run, on the end device or at a centralized location
on the network?  Is the idea to use a model like wireless telephony where
all of a users' service information is stored in a central network location
(the HLR)?

-----------------------------------------------------
Karen Goettler
phone - 303 734-5015
fax   - 303 734-4244
[email-masked]

PEAK Software Solutions, Inc.
7851 S Elati Street, Suite 200 Littleton, CO  80120
-----------------------------------------------------

---------