- From: RJ Auburn <rj@voxeo.com>
- Date: Sun, 31 Jul 2005 18:34:40 -0400
- To: Brian Frasca <frasca@tellme.com>
- Cc: <www-voice@w3.org>
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 UTC