Subject: CPL and FIP in this draft -- I-D ACTION:draft-ietf-iptel-cpl-framework-00.txt

From: Tom Gray <[email-masked]>
Date: Tue, 6 Jul 1999 07:13:34 -0700 (PDT)

--- [email-masked] wrote:
> A New Internet-Draft is available from the on-line
> Internet-Drafts directories.
> This draft is a work item of the IP Telephony
> Working Group of the IETF.
> 
> 	Title		: Call Processing Language Framework and
> Requirements
> 	Author(s)	: J. Lennox, H. Schulzrinne 
> 	Filename	: draft-ietf-iptel-cpl-framework-00.txt
> 	Pages		: 20
> 	Date		: 01-Jul-99
> 	
> A large number of the services we wish to make
> possible for Internet
> telephony require fairly elaborate combinations of
> signalling
> operations, often in network devices, to complete.
> We want a simple
> and standardized way to create such services to make
> them easier to
> implement and deploy.  This document describes an
> architectural
> framework for such a mechanism, 

I have read this draft and would like to re-issue a question that I
have asked before. What application is CPL directed to? This question
is pertinent due to the discussion in the document of the feature
interaction problem. I do not find that this section of the draft
adequately addresses the issue of FIP because the focus of the
application is not given.

If CPL is taken as a language that a user can use to create a set of
call handling features in similarity to the way that many current email
programs allow the creation of email filters, the feature interaction
problem does not arise. The application is small and the issues of
indeterminacy and user confusion do simply not arise. The draft should
be amended to identify this intended use and to state that for this
level of application FIP is not an issue.

If on the other hand, CPL is is intended for use in the creation of
fully featured call processing along the lines of PSTN or PBX
functionality then the discussion in the draft is inadequate to the
importance of the feature interaction problem. The draft identifies 
the issue of control indeterminacy and identifies that as a feature
interaction problem. To use the example in the draft, call waiting and
call forward on busy will both trigger on the receipt of a call on a
busy telephone. The claim is made that since CPL triggers on call
conditions and not on feature subscriptions that this problem of
control indeterminacy is addressed. However triggering on call
conditions is common place in call processing and the problems of
feature interaction still exists because the problem is much more than
the identification of this form of indeterminacy. Indeed features do
properly trigger on the same condition -- e.g. terminating call
screening and call forward always. This is a feature interaction but
not an undesirable one. Detection of undesirable interactions cannot
just be the detection of multiple features bound to the same call
condition. Thus the discussion in the draft does not directly address
the many issues of feature interaction. 

If CPL is intended to be used by designers of fully featured systems,
the draft should state that FIP must be addressed by these designers
and that CPL offers certain specific features which may partially
address some FIP issues.

_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com

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

---

From: Jonathan Lennox <[email-masked]>
Date: Fri, 9 Jul 1999 13:49:20 -0400 (EDT)

> level of application FIP is not an issue.

That is, indeed, the level of application I'm aiming the CPL at currently --
the e-mail filter analogy is a very good one.  I thought I had identified
this as the intended use in the current draft; it should probably be made
clearer.

It's generally true that if you give people a tool, they'll use it for
things far beyond what its designers originally envisioned it being used
for.  So I think that even though FIP isn't a problem for simple filter-like
use, FIP is still a problem that it's worth considering and thinking about.
 
> functionality

Like I said above it probably *could* be used for this; however, I think
that the restricted functionality of the CPL makes other tools more
appropriate for administrative feature design, where you shouldn't be
limited by the predictability and running-time constraints you need for
features designed by semi-untrusted users.

> then the discussion in the draft is inadequate to the

In this situation, yes, there is an interaction, and the responsibility is
on the CPL author to make sure the right result comes about.  If you look at
the actual design draft of the CPL, the feature you've mentioned looks
something like:

<string-switch field="from">
  <string matches="[email-masked]">
    <reject />
  </string>
  <otherwise>
    <proxy />
  </otherwise>
</string-switch>

I.e. the behavior is *explicit* in the language, and the feature designer is
forced to make an explicit choice about the behavior, which wouldn't happen
if each feature just specified a set of call events which would trigger it.
Does this address your concern?  If not, what other issues would you want to
be covered?

I think getting into this level of depth in the framework document is
perhaps somewhat inapproriate, since it depends on the actual design of the
language itself.  However, I  do agree that the solutions to this problem
should be more explicit there, so I'm not sure what the best way to address
this is.

-- 
Jonathan Lennox
[email-masked]

---------