Consolidated comments on CCXML from OptimSys (3)

Dear Voice Browser Working Group,

we have finished incorporating changes specified by the January version
of the CCXML working draft into the OptimTalk CCXML interpreter. The
rest of our comments on the CCXML draft can be found below. We hope that
you will be able to deal with these comments although they come after
the deadline.

The numbering of comments continues from our previous email (31 January
2005).

Best regards,

    Petr Kuba, Senior software architect
    OptimSys Ltd.
    kuba@optimsys.cz
    http://www.optimsys.cz



PROBLEM 28: Unclear attribute value
Location: 6.2.7.2

Rationale:
In the Attribute Details table of the <fetch> tag, the following valid
values are shown for the 'type' attribute: 'application/ccxml+xml',
'text/ecmascript', and 'text/javascript'. We do not understand when
the 'text/javascript' value could appear and what it should be used
for. Is the interpretation of this value equal to he 'text/ecmascript'
value?

Please, clarify this.

---
PROBLEM 29: missing information in the 'bridges' attribute of the
Conference class
Location: 10.3.1

Rationale:
The 'bridges' attribute stores only identifiers of connections,
conferences, and dialogs. These objects can be owned by various CCXML
sessions which store their object properties. However, it is not
possible to determine from the connection/conference/dialog ID the
CCXML session which owns it. Therefore, it is not possible (or at
least it is very difficult) to access the object properties or to
manipulate the object from an application.

Proposed change:
Besides the object ID, store also the ID of the CCXML session which
owns the object in the 'conference.bridges' array.

---
PROBLEM 30: Event 'conference.joined' / 'conference.unjoined' when
<join>ing / <unjoin>ing a conference
Location: 10.5.7.1, 10.5.8.1

Rationale:
In the specification, the following is stated: "Joining two objects
that are owned by separate CCXML sessions will result in the
generation of a conference.joined to each of the sessions." (similarly
for unjoining).

What if one of the objects is a conference? Shall a
'conference.(un)joined' event be sent to all the sessions attached to
this conference or shall it be sent only to the session which issued
the <join>/<unjoin> (if it is attached to the conference)?

Please, clarify this.

---
PROBLEM 31: Inconsistence in sending of 'conference.join' event for
<createcall>
Location: 10.4, 10.5.4.2

Rationale:
According to the 10.4, a 'conference.joined' event is sent for a
<createcall> having the 'joinid' attribute: "...when using
<createcall> with 'joinid', an event will be generated when the
requested bridge is established. ... If the bridge is established
successfully, the 'conference.joined' event is generated. If the
requested bridge cannot be established even after the call enters the
CONNECTED state, an error.conference.join' event will be generated..."

On the contrary, a 'joinid' attribute description in 10.5.4.2 states:
"This is equivalent, from the perspective of the CCXML application, to
performing a <join> immediately following the <createcall> except that
no events specific to the join will be generated."

Proposed change:
Omit the following part of the sentence in 10.5.4.2: "except that no
events specific to the join will be generated"

---
PROBLEM 32: Use <dialogterminate> tag instead of
'connection.disconnect.hangup' event
Location: Appendix D

Rationale:
The Second Last Working Draft of CCXML uses <dialogterminate> tag
instead of sending 'connection.disconnect.hangup' event directly in
the VoiceXML <disconnect> description. However, in the VoiceXML
<transfer> description, a 'connection.disconnect.hangup' event is used
directly. We believe that a <dialogterminate> should be used in this
case as well.

Proposed change:
Use the <dialogterminate> tag in the VoiceXML <transfer> example
instead of sending 'connection.disconnect.hangup' event directly.

Received on Monday, 4 April 2005 18:28:32 UTC