- From: Brian Frasca <frasca@tellme.com>
- Date: Fri, 29 Jul 2005 21:14:44 -0700
- To: <www-voice@w3.org>
- Message-ID: <B8E24C3AF01492459438BFA2D6ECBF7302491BFD@EXCH.sea.tellme.com>
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 07:22:12 UTC