Subject: [MEDIACTRL] Feedback on Basic IVR (draft-boulton-ivr-control-package-05) and multiple forms of XML

From: Dan York <[email-masked]>
Date: Mon, 4 Feb 2008 16:04:44 -0500

In light of some of my own work with VoiceXML and CCXML in recent  
weeks, I took another look at the Basic IVR draft:

    http://www.ietf.org/internet-drafts/draft-boulton-ivr-control- 
package-05.txt

and want to provide a bit of the perspective of a relative newcomer  
to this space.  Some of this feedback also reflects the many years I  
spent running IT training companies and developing courseware,  
teaching classes, managing trainers, etc.

First, as I said back at IETF 70, I remain concerned that we are  
creating "yet another XML flavor for IVR".  There's already VoiceXML,  
CCXML and then everyone in this space seems to have their own  
proprietary XML variant.  If I'm a newcomer into the world of VoIP  
and SIP who is looking to create a basic IVR system, I already have a  
confusing mix of choices.  Why are we at IETF introducing yet another  
flavor of XML?  Are we not just adding to the confusion for newcomers  
to the space?

Having said that, I do see the value in what is being proposed.  If  
you want to create a really basic IVR call flow, VoiceXML can be  
rather involved.  It's kind of like learning to fly the space shuttle  
when all you want to do is drive to the local convenience store.   I  
discovered myself that for some of the really basic things I wanted  
to do, Voxeo's own CallXML was MUCH simpler than VoiceXML or VoiceXML/ 
CCXML.  So I can see the value in a standardized "basic IVR" XML flavor.

However, it seems to me there are two challenges:

1. AVOIDING SCOPE CREEP - I think it is hard to draw a line around  
what exactly is a "basic" IVR implementation. I know that in Section  
1, the draft indicates:
 >   The scope of the package is control of media server functions for
 >   basic interactive media (e.g. play a prompt, collecting DTMF,
 >   recording user input) as well as notifications related to these
 >   functions.
My worry is that there will be an ongoing interest in expanding the  
definition of "basic" and pretty soon we are almost reinventing  
VoiceXML.  (i.e. successive iterations of "I don't want to have to go  
to full VoiceXML, but I just wish Basic IVR could do XXXXXX, why  
don't we add that?")

2. PROVIDING A CONSISTENT GROWTH PATH - If we want to prevent scope  
creep, one way to do so is to provide a very simple and easy "growth  
path" for the developer to move his/her XML code into a more advanced  
standardized XML version such as, in this instance, VoiceXML or CCXML  
(or a combination thereof).  Ideally, it would seem to me,  "Basic  
IVR" should simply be a subset of VoiceXML/CCXML so that someone  
learning "Basic IVR" who then wants more capabilities can simply  
learn the additional elements that he/she needs to learn in order to  
do whatever their advanced work is.

In reading the draft, though, it doesn't seem like the current  
definition is really a "subset" but rather is a different XML  
version. For instance, the <data> element defined in section 4.4 (and  
shown in use in 4.1.1) is a general block element and is not even  
remotely like the VoiceXML <data> element that sends information to  
an external program. ( http://docs.voxeo.com/voicexml/2.0/ 
data.htm ).  Instead of creating a new block element, could we not  
simply use the <block> element out of VoiceXML? ( http:// 
docs.voxeo.com/voicexml/2.0/block.htm )

Likewise, the <dialogstart> element defined in 4.1.2 seems to be  
quite similar to the CCXML <dialogstart> element ( http:// 
docs.voxeo.com/ccxml/1.0-final/dialogstart.htm ) except that some of  
the attributes are named differently.  For instance, in the draft  
there is "connection-id" whereas in CCXML there is "connectionid"  
with no dash. Similarly the draft has "conf-id" while CCXML has  
"conferenceid".

For an element like <dialogstart> which appears to be extremely close  
to the CCXML equivalent, can we just use the identical attribute  
names so that knowledge of one can transfer readily to the other?

Those are just two examples. I haven't gone through each of the  
elements listed in the draft.  My point is really that I think if we  
want this "Basic IVR" to be successful, we should: A) make it easy  
for developers to migrate up into VoiceXML/CCXML if they need more  
than what is in Basic IVR (i.e. so they are not here arguing Basic  
IVR should be extended); and B) make it easy for developers who  
*know* VoiceXML/CCXML to be able to migrate down into using Basic IVR  
to meet their needs.

If we can minimize the amount of additional learning that needs to  
take place as you moved between "basic" and "advanced" it would seem  
to me that we'll wind up helping build a stronger developer community  
around these technologies.

My 2 cents,
Dan

-- 
Dan York, CISSP, Director of Emerging Communication Technology
Office of the CTO    Voxeo Corporation     [email-masked]
Phone: +1-407-455-5859  Skype: danyork  http://www.voxeo.com
Blogs: http://blogs.voxeo.com  http://www.disruptivetelephony.com

Bring your web applications to the phone.
Find out how at http://evolution.voxeo.com

_______________________________________________
MEDIACTRL mailing list
[email-masked]
http://www.ietf.org/mailman/listinfo/mediactrl
Supplemental Web Site:
http://www.standardstrack.com/ietf/mediactrl

---

From: "Chris Boulton" <[email-masked]>
Date: Mon, 4 Feb 2008 21:21:42 -0000

First, as I said back at IETF 70, I remain concerned that we are
creating "yet another XML flavor for IVR".  There's already VoiceXML,
CCXML and then everyone in this space seems to have their own
proprietary XML variant.  If I'm a newcomer into the world of VoIP and
SIP who is looking to create a basic IVR system, I already have a
confusing mix of choices.  Why are we at IETF introducing yet another
flavor of XML?  Are we not just adding to the confusion for newcomers to
the space?

[Chris Boulton] Lets not forget - the IETF is not introducing 'yet
another flavor of XML'.  I'm assuming that the comparisons you are
making are to the MS* protocols and H.248.  We carried out a study of
exactly why H.248 was not a good fit on setting up the work group (I
think it was part of the charter proposal) and the MS* protocols are not
an IETF standards track solution.  They are informational RFC's:

IESG Note
 
   This RFC is not a candidate for any level of Internet Standard.  The
   IETF disclaims any knowledge of the fitness of this RFC for any
   purpose and in particular notes that the decision to publish is not
   based on IETF review for such things as security, congestion control,
   or inappropriate interaction with deployed protocols.  The RFC Editor
   has chosen to publish this document at its discretion.  Readers of
   this document should exercise caution in evaluating its value for
   implementation and deployment.  See RFC 3932 for more information.

So really, all we are specifying in MediaCtrl is a standards track,
complementary mechanism to VXML - this has been a goal since the outset.
If you want complex IVR - go use VXML.  If you want simple IVR and a way
to carrier pigeon VXML by value or by reference - use MediaCtrl.

I do fully agree with your feature creep statements - it is something
that we have been battling with, and will continue to battle with for a
long while to get the balance correct.

Chris.

---

From: "McGlashan, Scott" <[email-masked]>
Date: Thu, 7 Feb 2008 11:42:16 +0000

Hi Dan,

Thanks for the support and re-iterating our continuing goals to avoid feature creep and provide a consistent growth path. I want to pick up on a couple of points:

[1] Basic IVR as a subset of VoiceXML/CCXML versus a different XML application. There are 2 challenges to make it a subset. First, languages like VoiceXML come with their own interpretative framework, so it is not always obvious how to just extract parts of the language and use them standalone. The FIA (Form Interpretation Algorithm) in VoiceXML is an instance of this - it guides how dialogs are executed, prompts are queued and played, and how input from the user is mapped into the ECMAScript data model. Fortunately, W3C are already doing work on factoring VoiceXML 3.0 in modules and profiles, so we should leverage that work ensuring that the Basic IVR and VoiceXML 3.0 Media Server profile are as close as possible. The second challange is that VoiceXML is missing some features which may be regarded as 'basic' (and this is a feature creep issue). Examples include

- CCXML doesn't provide control over the multiple media streams (cf. basic IVR <stream> element)

- VoiceXML lacks VCR controls (speed, volume, seek) over prompt playback (basic IVR has some VCR controls). Note that VoiceXML 3.0 will address VCR controls, although the exact mechanisms are still under disucssion in W3C.

- VoiceXML lacks direct support for variable prompts (although the same functionality can be achieved through existing mechanism like <script>/<data> and <foreach>)

So if we want a proper subset of VoiceXML/CCXML we may need to re-consider these features and perhaps lose some capability in our basic language versus languages like MSCML and MSML.

Group feedback on these points is critical so we get the right balance between the basicness and usefulness of this package.

[2] <data> element in Basic IVR versus VoiceXML 2.1. While the element name is the same, they have very different internal structures and functions in the respective languages. In Basic IVR it is primarily a mechanism to return data (parameter value pairs) to the AS.  CCXML/VoiceXML use a namelist mechanism referencing ECMAScript variables to achieve this function (and I'm sure we don't want ECMAScript in the basic IVR package). I don't see much similarity with VoiceXML's <block> since it contains elements which are sequentially executed under the control of the FIA.  However, we can easily change the name in basic IVR if there is confusion - do you have a suggestion for an alternative name?

[3] Naming of connection and conference ids on <dialogstart>, <dialogprepare>. The names are determined by the SIP Control Framework and the IVR package (as well as conferencing and VoiceXML packages) simply use them. If we are comfortable that the meaning of the terms is sufficiently close to CCXML's usage, then I don't see a problem aligning the names in the SIP Control Framework.

[4] I would appreciate if you can continue to review the draft looking into the alignment of all element and attribute names. Where VoiceXML/CCXML has defined an appropriate name, I have used them in Basic IVR. Any comments on the proposed spec changes in my email of 2007-12-07, are also most welcome since I'm about to update the spec.

thanks

Scott

________________________________
From: [email-masked] [mailto:[email-masked]] On Behalf Of Dan York
Sent: Monday, February 04, 2008 22:05
To: [email-masked]
Subject: [MEDIACTRL] Feedback on Basic IVR (draft-boulton-ivr-control-package-05) and multiple forms of XML

In light of some of my own work with VoiceXML and CCXML in recent weeks, I took another look at the Basic IVR draft:

   http://www.ietf.org/internet-drafts/draft-boulton-ivr-control-package-05.txt

and want to provide a bit of the perspective of a relative newcomer to this space.  Some of this feedback also reflects the many years I spent running IT training companies and developing courseware, teaching classes, managing trainers, etc.

First, as I said back at IETF 70, I remain concerned that we are creating "yet another XML flavor for IVR".  There's already VoiceXML, CCXML and then everyone in this space seems to have their own proprietary XML variant.  If I'm a newcomer into the world of VoIP and SIP who is looking to create a basic IVR system, I already have a confusing mix of choices.  Why are we at IETF introducing yet another flavor of XML?  Are we not just adding to the confusion for newcomers to the space?

Having said that, I do see the value in what is being proposed.  If you want to create a really basic IVR call flow, VoiceXML can be rather involved.  It's kind of like learning to fly the space shuttle when all you want to do is drive to the local convenience store.   I discovered myself that for some of the really basic things I wanted to do, Voxeo's own CallXML was MUCH simpler than VoiceXML or VoiceXML/CCXML.  So I can see the value in a standardized "basic IVR" XML flavor.

>   recording user input) as well as notifications related to these
My worry is that there will be an ongoing interest in expanding the definition of "basic" and pretty soon we are almost reinventing VoiceXML.  (i.e. successive iterations of "I don't want to have to go to full VoiceXML, but I just wish Basic IVR could do XXXXXX, why don't we add that?")

2. PROVIDING A CONSISTENT GROWTH PATH - If we want to prevent scope creep, one way to do so is to provide a very simple and easy "growth path" for the developer to move his/her XML code into a more advanced standardized XML version such as, in this instance, VoiceXML or CCXML (or a combination thereof).  Ideally, it would seem to me,  "Basic IVR" should simply be a subset of VoiceXML/CCXML so that someone learning "Basic IVR" who then wants more capabilities can simply learn the additional elements that he/she needs to learn in order to do whatever their advanced work is.

In reading the draft, though, it doesn't seem like the current definition is really a "subset" but rather is a different XML version. For instance, the <data> element defined in section 4.4 (and shown in use in 4.1.1) is a general block element and is not even remotely like the VoiceXML <data> element that sends information to an external program. ( http://docs.voxeo.com/voicexml/2.0/data.htm ).  Instead of creating a new block element, could we not simply use the <block> element out of VoiceXML? ( http://docs.voxeo.com/voicexml/2.0/block.htm )

Likewise, the <dialogstart> element defined in 4.1.2 seems to be quite similar to the CCXML <dialogstart> element ( http://docs.voxeo.com/ccxml/1.0-final/dialogstart.htm ) except that some of the attributes are named differently.  For instance, in the draft there is "connection-id" whereas in CCXML there is "connectionid" with no dash. Similarly the draft has "conf-id" while CCXML has "conferenceid".

For an element like <dialogstart> which appears to be extremely close to the CCXML equivalent, can we just use the identical attribute names so that knowledge of one can transfer readily to the other?

Those are just two examples. I haven't gone through each of the elements listed in the draft.  My point is really that I think if we want this "Basic IVR" to be successful, we should: A) make it easy for developers to migrate up into VoiceXML/CCXML if they need more than what is in Basic IVR (i.e. so they are not here arguing Basic IVR should be extended); and B) make it easy for developers who *know* VoiceXML/CCXML to be able to migrate down into using Basic IVR to meet their needs.

If we can minimize the amount of additional learning that needs to take place as you moved between "basic" and "advanced" it would seem to me that we'll wind up helping build a stronger developer community around these technologies.

My 2 cents,
Dan

--
Dan York, CISSP, Director of Emerging Communication Technology
Office of the CTO    Voxeo Corporation     [email-masked]<mailto:[email-masked]>
Phone: +1-407-455-5859  Skype: danyork  http://www.voxeo.com
Blogs: http://blogs.voxeo.com  http://www.disruptivetelephony.com