W3C home > Mailing lists > Public > www-voice@w3.org > July to September 2005

Re: Comments on the CCXML WD of 29 June 2005

From: RJ Auburn <rj@voxeo.com>
Date: Sun, 31 Jul 2005 18:34:40 -0400
Message-Id: <ABFB429E-AE50-411F-9DB0-4CE17A5C84BC@voxeo.com>
Cc: <www-voice@w3.org>
To: Brian Frasca <frasca@tellme.com>

Brian,

Thank you for your comments on the CCXML LCWD. The working group will  
review these on an upcoming teleconference and report back the  
results of the review.

Thanks again,

     RJ


---
RJ Auburn
CTO, Voxeo Corporation
tel:+1-407-418-1800



On Jul 30, 2005, at 24:14 AM, Brian Frasca wrote:



> Voice Browser Working Group,
>
>
>
> The CCXML working draft is looking very good.  Thanks for your  
> efforts!
>
>
>
> Below are some comments/questions on the latest draft (29 June  
> 2005) listed in document order.
>
>
>
> Thanks again for the hard work,
>
>
>
> Brian Frasca
>
> Tellme Networks
>
> frasca@tellme.com
>
>
>
> ----------------------------------------
>
>
>
> 1.  In section 3, the description for "Voice Dialog" says that it  
> is associated with an underlying connection that is distinct from  
> the other connections and conferences that it can be joined with.   
> This makes total sense from an implementation point of view.   
> However, there are a lot of properties for connection objects that  
> aren't exposed for dialog objects (e.g. local, remote, protocol,  
> aai, etc.).  Should these properties or the underlying connection  
> object itself be exposed to the CCXML application?
>
>
>
> ----------------------------------------
>
>
>
> 2.  Section 3 says that connection objects cannot accept events.   
> Why not?  There may be cases where you want to send extra  
> information to a connection end-point and it would be nice if you  
> could do this using a <send> with the connection id as the target.   
> If the underlying signaling is done using SIP, for example, this  
> could translate into a SIP INFO message to the specified connection.
>
>
>
> ----------------------------------------
>
>
>
> 3.  Section 3.4 says, "Scope element - a CCXML variable name which  
> defines a variable scope..."  Should the phrase "CCXML variable  
> name" be "CCXML element" instead?
>
>
>
> ----------------------------------------
>
>
>
> 4.  Section 3.5.3.8 says that using an optional "master" session  
> for inbound calls is equivalent to having multiple sessions <move>  
> their inbound calls to a single session.  However, the diagram in  
> section 3.5.3.8 shows the master session receiving  
> connection.alerting events for each inbound call.
>
>
>
> According to section 9.2.4, on the other hand, it seems like if a  
> <move> is done on an inbound call that the initial session will  
> receive the connection.alerting event and the target session to  
> which the call is moved will not.
>
>
>
> Which case is correct?  Perhaps a master session isn't quite  
> equivalent to multiple moves?
>
>
>
> ----------------------------------------
>
>
>
> 5.  In section 5, the description for <move> says, "Move a  
> event..."  Should that phrase read "Move an event source..." instead?
>
>
>
> ----------------------------------------
>
>
>
> 6.  In section 6.2.7.2, the description of the fetchid attribute of  
> <fetch> says, "... even if the request if for the same URL."  This  
> should read, "... even if the request *is* for the same URL."
>
>
>
> ----------------------------------------
>
>
>
> 7.  In section 6.2.9.2, the description of the timeout attribute of  
> <createccxml> says that an error.fetch event will be posted if the  
> timeout expires.  Should an error.createccxml event be posted  
> instead or at least in addition?
>
>
>
> Also, what error event(s) should be posted if the initial document  
> cannot be fetched because it is older than maxage/maxstale allow?   
> Again I would favor a single error.createccxml event and no  
> error.fetch event.  It would be nice to be able to handle a single  
> error event for <createccxml> failures.
>
>
>
> ----------------------------------------
>
>
>
> 8.  Sections 6.2.9 and 6.3.  If a session created by <createccxml>  
> fails during document initialization (e.g. due to an ECMAScript  
> error) should the parent session receive an error.createccxml event  
> or a ccxml.created event?  I assume that if such an error occurs  
> after document initialization (i.e. after ccxml.loaded is sent to  
> the new session) then the parent session will have already received  
> ccxml.created and will not receive error.createccxml.
>
>
>
> ----------------------------------------
>
>
>
> 9.  Section 6.3.4 says that a ccxml.exit event is generated when a  
> document executes an <exit>.  However, if a child session  
> terminates without executing <exit> but instead due to an unhandled  
> "error.*" or kill event, will the parent session receive any event  
> notifying it of the child's demise?  It seems useful to notify the  
> parent for any termination condition.
>
>
>
> ----------------------------------------
>
>
>
> 10.  Section 6.3.6 notes that an event I/O processor can generate a  
> "standard" event such as ccxml.kill.  What happens if a standard  
> event is generated that does not include all of the required  
> fields?  If the receiving document tries to access a missing  
> required field will an error.semantic event be generated?  Can/ 
> should the platform do any sanity checking and reject malformed  
> events?
>
>
>
> Furthermore, even if all required fields are present the values  
> might still be invalid (e.g. ids that don't exist) or the event  
> itself could even be incorrect (e.g. claiming that an ongoing fetch  
> has completed before it really has).
>
>
>
> In general, how much freedom does a platform have to detect and  
> reject incorrect or malicious events?
>
>
>
> ----------------------------------------
>
>
>
> 11.  In section 7.1, the first example includes the following  
> transition:
>
>
>
> <transition event="connection.connected" name="evt">
>
>     <dialogstart prepareddialogid="evt.dialogid"
>
>                     connectionid="evt.connectionid"/>
>
> </transition>
>
>
>
> Should "evt.dialogid" be "evt.connection.dialogid" instead?
>
>
>
> ----------------------------------------
>
>
>
> 12.  Section 7.1 shows a pattern for using <dialogprepare> on an  
> inbound call.  Is there an equivalent pattern for an outbound  
> call?  Would the following be the correct pattern?
>
>
>
> <transition event="..." name="evt">
>
>     <dialogprepare src="..."> <!-- no connectionid -->
>
> </transition>
>
> <transition event="dialog.prepared" name="evt">
>
>     <createcall dest="..." joinid="evt.dialogid"> <!-- use joinid -->
>
> </transition>
>
> <transition event="connection.connected" name="evt">
>
>     <dialogstart prepareddialogid="evt.connection.dialogid"
>
>                  connectionid="evt.connectionid"/>
>
> </transition>
>
>
>
> Perhaps it's worth including an outbound example in this section?
>
>
>
> ----------------------------------------
>
>
>
> 13.  In section 7.1, all of the patterns show the <dialogstart>  
> occurring after the <accept>.  However, I didn't see anything that  
> explicitly states this must be the case.  Is it legal for a  
> <dialogstart> to be executed against a connection that is in the  
> alerting or progressing state or is it required that the connection  
> be in the connected state?
>
>
>
> Perhaps more to the point, in general, what is it possible to do  
> with a connection before accepting it?  For example, is it possible  
> to play a custom ringback tone before accepting the call or play an  
> Intercept announcement like "The number you dialed has changed.   
> Please check the number..." or "The number you dialed is no longer  
> in service..." without ever answering/accepting the call.
>
>
>
> ----------------------------------------
>
>
>
> 14.  The end of section 7.1 states:  "It is possible for Dialogs to  
> exist that are not joined to a Connection.  For example this could  
> be due to a Connection disconnecting or the user performing an  
> <unjoin/> operation."
>
>
>
> Is it possible, however, for a dialog to be started without  
> initially being joined to any connection or conference?
>
>
>
> Will this happen if (1) neither a connectionid nor conferenceid is  
> specified on both the <dialogprepare> (if present) and  
> <dialogstart> and (2) the event triggering the transition  
> containing <dialogstart> does not contain a connection or  
> conference id (e.g. ccxml.loaded)?  Or, will that scenerio result  
> in an error and if so which one?
>
>
>
> If it's legal for a dialog to be started in such a state, then is  
> it possible to do this from a transition triggered by an event  
> containing a connection?  In other words, is it possible to mask  
> what would otherwise be the default connectionid for  
> <dialogstart>?  If so, how?
>
>
>
> If it's not legal for dialog to start off "unjoined" then that  
> seems a little asymmetric.  If there's ever a valid use case for  
> having an unjoined dialog (perhaps having it already running in the  
> background so you can quickly join a call to it) then not being  
> able to create a dialog in that state may lead to awkward hacks in  
> application code.  On the other hand, if there's never a valid use  
> case for having an unjoined dialog then why is it permitted?
>
>
>
> ----------------------------------------
>
>
>
> 15.  Section 7.2.  If a dialog is terminated with <dialogterminate>  
> while it is still being prepared (i.e. before the dialog.prepared  
> event is processed) which event(s) should be posted?   
> error.dialog.notprepared?  dialog.exit?  Both?
>
>
>
> Section 7.2.1.1 states that an error.dialog.notprepared event  
> should be posted if the dialog cannot be prepared for any reason.   
> Section 7.2.3.1 implies that a <dialogterminate> will always result  
> in a dialog.exit event being posted.  If these are both true then I  
> would expect both events to be posted.
>
>
>
> If both events are posted then is there a required ordering?  For  
> example, should the error.dialog.notprepared always be delivered  
> before the dialog.exit?
>
>
>
> What should happen if there is already a dialog.prepared event in  
> the queue when the <dialogterminate> is processed?  Should the  
> dialog.prepared event still be delivered followed later by a  
> dialog.exit event?
>
>
>
> ----------------------------------------
>
>
>
> 16.  Section 7.2.  <fetch> and <createccxml> both have a timeout  
> attribute.  For similar reasons, should <dialogstart> and  
> <dialogprepare> also have a timeout attribute?
>
>
>
> Furthermore, is it legal for a platform to have built-in timeout  
> periods of its own?  For example, can a platform decide that if it  
> ever takes more than 30 seconds to fetch a document it will abort  
> the fetch and post an error.fetch event?  Is it legal for the  
> platform to abort a fetch after 30 seconds even if the application  
> specifies 60 seconds in the timeout field?
>
>
>
> ----------------------------------------
>
>
>
> 17.  Section 7.2.  If the dialogid attribute is included both in a  
> <dialogprepare> element and its associated <dialogstart> element,  
> is it required that the value returned be identical in both cases?   
> I assume (and very much hope) that the ids must match but it might  
> be worth stating this explicitly one way or the other.
>
>
>
> ----------------------------------------
>
>
>
> 18.  Section 7.2.1.1 says that if a dialog manager does not support  
> preparation then the plaform must save the values that were  
> provided in the src, namelist, and connectionid attributes (for use  
> in a subsequent <dialogstart>).  Wouldn't the platform also have to  
> save the values of the other attributes as well (e.g. type,  
> conferenceid, etc.)?
>
>
>
> ----------------------------------------
>
>
>
> 19.  Section 7.2.2.1 says that the dialog.exit event will be posted  
> to the event queue of the CCXML session that started it.  If the  
> dialog was moved (via <move>), however, wouldn't the dialog.exit  
> event be posted to the new "owner" session?
>
>
>
> ----------------------------------------
>
>
>
> 20.  In section 7.2.2.2, the description of the prepareddialogid  
> attribute of <dialogstart> refers to the "error.dialogwrongstate"  
> event.  I believe this should be the "error.dialog.wrongstate" event.
>
>
>
> Also, is this event posted instead of or in addition to the usual  
> error.dialog.notstarted event?  Section 7.2.2.1 says that an  
> error.dialog.notstarted event is posted if the dialog cannot be  
> started for "any" reason so I would expect that either both events  
> are posted or else that wording is too strong.
>
>
>
> Posting two separate events for a single error seems a little  
> confusing.  On the other hand, having to catch two different events  
> to handle <dialogstart> errors seems a bit awkward (and  
> "error.dialog.*" doesn't quite work since it pulls in  
> error.dialog.notprepared).
>
>
>
> Is it really important to use an error.dialog.wrongstate event or  
> would it be better to just use a single error.dialog.notstarted  
> event for all cases when <dialogstart> fails?
>
>
>
> ----------------------------------------
>
>
>
> 21.  In section 7.2.2.2, the descriptions of both the connectionid  
> and conferenceid attributes of <dialogstart> say that they will  
> post an "error.fetch" event if both are specified.  Wouldn't it be  
> more consistent to post an "error.dialog.notstarted" event  
> instead?  Or is the intention that both error events should be  
> posted?  As noted above, posting multiple error events for a single  
> error seems confusing.
>
>
>
> ----------------------------------------
>
>
>
> 22.  Section 7.2.2.2.  What does it mean if any of the maxstage,  
> maxstale, enctype, or method attributes are specified in both a  
> <dialogprepare> element and its associated <dialogstart> element?   
> Are these attributes ignored in the <dialogstart> element?  Should  
> it be invalid to include them in conjunction with the  
> prepareddialogid attribute?
>
>
>
> ----------------------------------------
>
>
>
> 23.  Section 7.3.3.  What happens if a dialog terminates normally  
> concurrently with the CCXML application executing a  
> <dialogterminate>?  Is the platform required to detect this and  
> only post a single dialog.exit event?  It seems like that should be  
> the case or else it may complicate the application logic.
>
>
>
> ----------------------------------------
>
>
>
> 24.  Section 7.4.  The duplex properties of a dialog object is  
> allowed to have the values "full", "half", or "undefined".  If set  
> to "half" the description states that the dialog is *receiving* a  
> media stream.  However, the mediadirection attribute of  
> <dialogprepare> and <dialogstart> allows "dialogtransmit" as well  
> as "dialogreceive" to be specified.  Shouldn't the duplex property  
> distinguish which direction the media is streaming for half duplex  
> connections?
>
>
>
> Also, in the same description, "froma" should be "from a".
>
>
>
> ----------------------------------------
>
>
>
> 25.  In section 8.2.1.2, the type for the "name" attribute of <var>  
> is listed as "ECMAScript Expression".  Should this type "string"  
> instead?  All of the examples use simple unquoted strings for this  
> field.
>
>
>
> ----------------------------------------
>
>
>
> 26.  In section 8.2.1.2, the table states that the "expr" attribute  
> of <var> is not required and has no default value but that it must  
> be a valid ECMAScript expression.  Should the default value be the  
> ECMAScript "undefined" value?
>
>
>
> ----------------------------------------
>
>
>
> 27.  Section 8.2.2.2.  The type for the timeout, maxage, maxstale,  
> and charset attributes of <script> is "Character string".  Should  
> the type be "ECMAScript Expression" instead?  Other elements such  
> as <dialogstart> allow the timeout, maxage, and maxstale attributes  
> to be expressions.
>
>
>
> ----------------------------------------
>
>
>
> 28.  In section 9.2.2.2, the table states that the "name" attribute  
> of <transition> is supposed to be "An ECMAScript left hand side  
> expression evaluating to a previously defined variable."  However,  
> none of the examples in the spec ever use <var> to declare the  
> event variable.  Does the event variable really need to be  
> previously declared?  If so, then the examples should probably be  
> fixed.
>
>
>
> ----------------------------------------
>
>
>
> 29.  In section 10.2.1, the diagram shows a connection.signal  
> transition from the PROGRESSING state but the table does not.
>
>
>
> ----------------------------------------
>
>
>
> 30.  Section 10.5.2.  What event should be posted if <redirect>  
> fails?  Should there be an error.redirect event analogous to the  
> error.merge event?
>
>
>
> ----------------------------------------
>
>
>
> 31.  In sections 10.5.2.2 and 10.5.4.2, the descriptions for dest  
> attribute of <redirect> and <createcall> state "A platform must  
> support a telephone URI, as described in [RFC2806] or a SIP URI as  
> described in [RFC3261]."  Is this saying a platform must support  
> both RFCs or at least one of them?
>
>
>
> ----------------------------------------
>
>
>
> 32.  Section 11.1.
>
>
>
> > <!-- Set our initial state -->
>
> > <assign name="currentstate" expr="'initial'" />
>
>
>
> This should use <var> instead of <assign>.
>
>
>
> > <!-- happens when pin.vxml VoiceXML dialog thread exits -->
>
> > <transition state="in_vxml_session" event="dialog.exit" name="evt">
>
> >     <createcall dest="evt.values.telnum" name="out_connectionid" />
>
> >     <assign name="currentstate" expr="'calling'" />
>
> > </transition>
>
>
>
> The value of evt.values.telnum is a 7-digit number.  Is that a  
> valid RFC2806 URL?
>
>
>
> There is no "name" attribute for the <createcall> element.  It  
> should be "connectionid" instead.
>
>
>
> ----------------------------------------
>
>
>
> 33.  Section 11.3.
>
>
>
> > <assign expr="evt.accepted" name="accepted" />
>
>
>
> The namelist returned by outbound_greetings.vxml used a variable  
> named "willaccept".  Should "evt.accepted" be changed to  
> "evt.values.willaccept"?
>
>
>
> ----------------------------------------
>
>
>
> 34.  Appendix D contain this sentence:  "The sections below define  
> the eventing relationship between the CCXML and VoiceXML  
> environments."  Should "eventing" be changed to "event"?
>
>
>
> ----------------------------------------
>
>
>
> 35.  Section D.11 (VoiceXML 2.0 Example).
>
>
>
> The variables "maxtime_sendid" and "evt" are not declared.
>
>
>
> --------------------
>
>
>
> > Handle an transfer request from a VXML script.
>
>
>
> Should read: "Handle a transfer..."
>
>
>
> --------------------
>
>
>
> > <send data="connection.disconnect.transfer" ....
>
> > <send data="dialog.transfer.complete" ....
>
>
>
> The data attribute is an ECMAScript expression so these strings  
> should be inside single quotes.
>
>
>
> --------------------
>
>
>
> > <assign name="results" ....
>
>
>
> Either the "results" variable should be declared under <ccxml> or  
> else the places where <assign> is used on it should be changed to  
> <var>.
>
>
>
> --------------------
>
>
>
> > <!-- Join the two calls together -->
>
> > <join id1="in_connectionid" id2="in_connectionid" duplex="full" />
>
>
>
> One of the connection ids should be out_connectionid.  BTW, what  
> will happen if both ids being joined are the same?  Will it  
> generate an error or will the caller be talking to themself?
>
>
>
> --------------------
>
>
>
> > <!-- If maxtime has been set then we setup a timer -->
>
> > <if cond="vxml_maxtime != undefined">
>
> >     <send data="maxtime"
>
> >         target="session.id"
>
> >         delay="vxml_maxtime"
>
> >         sendid="maxtime_sendid"/>
>
> > </if>
>
>
>
> There is no variable "maxtime" declared and the event that is  
> waited for later is named 'vxml_maxtime'.  Should this be:
>
>
>
>     <send data="'vxml_maxtime'" ....>
>
>
>
> --------------------
>
>
>
> > <assign name="results" expr="far_end_disconnect" />
>
> > <assign name="results" expr="near_end_disconnect" />
>
> > <assign name="results" expr="maxtime_disconnect" />
>
>
>
> The expression is a string so it should be in single quotes.
>
>
>
> --------------------
>
>
>
> > <assign name="mystate" expr="'userDisconnected'" />
>
>
>
> Elsewhere, the state is called 'userDisconnect'.
>
>
>
> --------------------
>
>
>
> > - We are only going to deal with stuff if it the event is
>
>
>
> Should read: "...stuff if the event..."
>
>
>
> --------------------
>
>
>
> > - Should this happen we just disconnect the outbound call let
>
>
>
> Should read: "...outbound call leg..."
>
>
>
>
>
>
Received on Sunday, 31 July 2005 22:35:46 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Monday, 30 October 2006 12:49:01 GMT