W3C

CCXML 1.0: Last Call Working Draft Disposition of Comments

This version:
13 December 2009
Editor:
RJ Auburn, Voxeo

Abstract

This document details the responses made by the Voice Browser Working Group to issues raised during the Last Call Working Draft period (beginning 19 January 2007 and ending 13 December 2009). www-voice-request@w3.org( archive) mailing list.

Status

This document of the W3C's Voice Browser Working Group describes the disposition of comments as of 13 December 2009 on the Last Call Working Draft Voice Browser Call Control XML (CCXML) Version 1.0.It may be updated, replaced or rendered obsolete by other W3C documents at any time.

For background on this work, please see the Voice Browser Activity Statement.

Comment summary

Legend:

ACCEPTED Comment was accepted
TEXTSUPERSEDED Text that was commented on had already been changed.
CLARIFICATION Comment only required a clarification.
DROPPED Feature in question was removed from the spec.
REASSIGNEDID Issue number was changed to a new ID
IMPLICIT Resolution was implicitly accepted by original commenter based on no response on mailing list.
EXPLICIT Resolution was explicitly accepted by original commenter on mailing list.

Results:

ID Title Date Opened Last Updated Disposition Acceptance Related Issues
ISSUE-105 PUBLIC - LCWD - Query in CCXML 1.0 Specification 2007-02-08 2007-04-30 REASSIGNEDID NA 222,223,224,225,226,227,228
ISSUE-106 PUBLIC - LCWD - Query regarding <dialogstart> command 2007-02-08 2007-12-12 REASSIGNEDID NA 229
ISSUE-107 PUBLIC - LCWD - Comments on CCXML Working Draft 19 January 2007 2007-02-08 2007-04-30 REASSIGNEDID NA 230,231
ISSUE-108 PUBLIC - LCWD - Comments on CCXML Working Draft 19 January 2007 (2) 2007-02-08 2008-03-26 REASSIGNEDID NA 232
ISSUE-109 PUBLIC - LCWD - querry 2007-02-08 2008-03-26 REASSIGNEDID NA 233
ISSUE-110 PUBLIC - LCWD - query. 2007-02-08 2008-04-23 REASSIGNEDID NA 234
ISSUE-111 PUBLIC - CCXML 2007-02-08 2008-01-30 CLARIFICATION IMPLICIT NONE
ISSUE-112 PUBLIC - VXML-CCXML integration - Updating VoiceXML session variables 2007-02-08 2008-05-12 DROPPED IMPLICIT NONE
ISSUE-115 LCWD - Comments from i18n core WG on CCXML 2007-02-08 2008-12-10 ACCEPTED EXPLICIT NONE
ISSUE-116 LCWD - error.semantic/hints 2007-02-08 2007-05-29 ACCEPTED EXPLICIT NONE
ISSUE-222 PUBLIC - LCWD - Nagesh S-1 - Query in CCXML 1.0 Specification. 2007-04-30 2007-09-19 ACCEPTED IMPLICIT NONE
ISSUE-223 PUBLIC - LCWD - Nagesh S-2 - Query in CCXML 1.0 Specification. 2007-04-30 2007-09-12 CLARIFICATION IMPLICIT NONE
ISSUE-224 PUBLIC - LCWD - Nagesh S-3 - Query in CCXML 1.0 Specification. 2007-04-30 2007-09-12 ACCEPTED IMPLICIT NONE
ISSUE-225 PUBLIC - LCWD - Nagesh S-4 - Query in CCXML 1.0 Specification. 2007-04-30 2009-01-08 ACCEPTED IMPLICIT NONE
ISSUE-226 PUBLIC - LCWD - Nagesh S-5 - Query in CCXML 1.0 Specification. 2007-04-30 2007-09-12 ACCEPTED IMPLICIT NONE
ISSUE-227 PUBLIC - LCWD - Nagesh S-6 - Query in CCXML 1.0 Specification. 2007-04-30 2009-01-08 ACCEPTED IMPLICIT NONE
ISSUE-228 PUBLIC - LCWD - Nagesh S-7 - Query in CCXML 1.0 Specification. 2007-04-30 2007-09-26 ACCEPTED IMPLICIT NONE
ISSUE-229 PUBLIC - LCWD - Sajeesh-1 [CCXML] Query regarding <dialogstart> command 2007-04-30 2007-12-12 TEXTSUPERSEDED IMPLICIT NONE
ISSUE-230 PUBLIC - LCWD - Nezic-1 - Comments on CCXML Working Draft 19 January 2007 2007-04-30 2007-05-30 ACCEPTED EXPLICIT NONE
ISSUE-231 PUBLIC - LCWD - Nezic-2 - Comments on CCXML Working Draft 19 January 2007 2007-04-30 2007-09-12 TEXTSUPERSEDED IMPLICIT NONE
ISSUE-232 PUBLIC - LCWD - Nezic-3 - Comments on CCXML Working Draft 19 January 2007 (2) 2007-04-30 2008-03-26 TEXTSUPERSEDED IMPLICIT NONE
ISSUE-233 PUBLIC - LCWD - murulidhara-1 - querry 2007-04-30 2008-03-26 CLARIFICATION IMPLICIT NONE
ISSUE-234 PUBLIC - LCWD - murulidhara-2 - query. 2007-04-30 2008-04-23 TEXTSUPERSEDED IMPLICIT NONE
ISSUE-235 PUBLIC - LCWD - murulidhara-3 - CCXML : Query regarding error.semantic 2007-04-30 2008-01-30 TEXTSUPERSEDED IMPLICIT NONE
ISSUE-236 PUBLIC - LCWD - Kuba-1 - CCXML: Dialog and Connection objects 2007-04-30 2008-04-23 TEXTSUPERSEDED EXPLICIT NONE
ISSUE-237 PUBLIC - LCWD - Kuba-2 - CCXML: Dialog and Connection objects 2007-04-30 2008-03-27 TEXTSUPERSEDED EXPLICIT NONE
ISSUE-238 PUBLIC - LCWD - Sajeesh-2 [CCXML]Regarding namelist attribute 2007-04-30 2007-12-19 ACCEPTED IMPLICIT NONE
ISSUE-325 PUBLIC - CCXML state variable 2008-01-31 2008-05-18 ACCEPTED IMPLICIT NONE
ISSUE-524 PUBLIC - <disconnect/> on outbound call 2008-07-17 2008-11-23 ACCEPTED EXPLICIT NONE
ISSUE-525 PUBLIC - Notification of implicit bridge teardowns 2008-07-17 2009-01-07 CLARIFICATION IMPLICIT NONE
ISSUE-553 PUBLIC - Incorrect example in the CCXML spec 2008-11-13 2008-12-10 CLARIFICATION EXPLICIT NONE
ISSUE-569 PUBLIC - posting ccxml.exit to parent upon child getting a ccxml.kill event 2009-02-12 2009-03-26 CLARIFICATION IMPLICIT NONE
ISSUE-570 PUBLIC - CCXML WD 19012007 - Limiting amount of connection inputs and other comments 2009-02-19 2009-07-15 CLARIFICATION EXPLICIT NONE
ISSUE-614 PUBLIC - Reg execution of subsequent elements after an event is encountered for current element in <transition> 2009-07-16 2009-07-22 TEXTSUPERSEDED IMPLICIT NONE
ISSUE-633 PUBLIC - using Object in the application scope - example error 2009-10-22 2009-12-07 ACCEPTED IMPLICIT NONE
ISSUE-637 PUBLIC - Comments on CCXML specification - Attribute 'info' in the conference.created and conference.destroyed events 2009-10-22 2009-12-07 ACCEPTED IMPLICIT NONE

Issue detail

ISSUE-105 - PUBLIC - LCWD - Query in CCXML 1.0 Specification

Tracker (W3C Member only):

ISSUE-105

Opened: 2007-02-08

Last Updated: 2009-11-19 10:52

State: CLOSED

Description:

http://lists.w3.org/Archives/Public/www-voice/2007JanMar/0027.html


Hi, 

         Please find some of the queries/changes in the CCXML 1.0,  w3c
working draft 19 January 2007,

1)       For the Event, error.createccxml in the section 6.3.8, the
\"required\" field is not mentioned properly, it should be \"true\".

2)       In the events like error.move, error.send.failed, the reason
attribute is a mandatory attribute but whereas for the event,
connection.disconnected, connection.redirected, and connection.failed, the
reason attribute is optional, is it intentional?

3)       For the <createcall> element, attribute constraints missing for the
attribute \"joinid\" and \"joindirection\", saying that the latter should be
present if the former is present.

4)       The DTD file present in the location,
http://www.w3.org/TR/ccxml/ccxml.dtd. is not consistent with the element
attributes mentioned in the specification. Eg: in the <send> element, the
attribute data is removed but the DTD is not updated for the same, it is
still reflecting data attribute.

5)       The example given in the section, 10.2.5 does not reflect the new
way of accessing the event attributes using the event$.

6)       In the DTD file present in the location,
http://www.w3.org/TR/ccxml/ccxml.dtd., xmlns attribute is not made a valid
attribute for the element <ccxml> and <send> so the DTD validation of the
valid CCXML 1.0 complaint document fails when the xmlns attribute is present
in the document. 

7)       The connection state diagram provided in the section 10.2.1, the
connection state transition from ALERTING to FAILED, can happen because of
the \"connection.rejected\" event, but the same is not present in the
specification. My doubt is when the state of the connection transitions to
FAILED state after issuing the <reject> command.

 

Thanks in advance for replying to the queries,

Regards,

Nagesh.

Notes:

Related e-mails:

ISSUE-106 - PUBLIC - LCWD - Query regarding <dialogstart> command

Tracker (W3C Member only):

ISSUE-106

Opened: 2007-02-08

Last Updated: 2009-12-13 09:11

State: CLOSED

Description:

http://lists.w3.org/Archives/Public/www-voice/2007JanMar/0028.html

Hi, 

  In section 7.2.2.1 of W3C working draft for Voice browser call control - CCXML,  It says that

\"If the prepareddialogid attribute is specified and any attribute values  conflict with the values specified 
in the 
<dialogprepare> element this  MUST result in the throwing of an error.dialog.notstarted event\"

In this case, should we check all attributes of <dialogstart> like connectionid/conferenceid, maxage, 
maxstale, enctype, method and hints against the corresponding <dialogprepare> command? 

Or only the checking of mediadiection (which is explicitly specified in CCXML draft) is enough?

Regards,
Sajeesh

Notes:

Related e-mails:

ISSUE-107 - PUBLIC - LCWD - Comments on CCXML Working Draft 19 January 2007

Tracker (W3C Member only):

ISSUE-107

Opened: 2007-02-08

Last Updated: 2009-12-13 09:14

State: CLOSED

Description:

http://lists.w3.org/Archives/Public/www-voice/2007JanMar/0030.html

6.2.7: <fetch>

Current text:
\"The event is one of fetch.done, which indicates that the identified content 
was fetched successfully, or error.fetch, indicative of a failure to fetch 
the requested content.\"

Proposed text:
\"The event is one of fetch.done, which indicates that the identified content 
was fetched successfully and in case of CCXML document, XML parsing / 
validation was performed, or error.fetch, indicative of a failure to fetch 
the requested content. \"

It is not quite clear from the description of <fetch> what the CCXML 
interpreter should perform before its sends the fetch.done event.

6.2.2.2: <meta> Attribute Details

Current text:
\" Either the name or the http-equiv attribute has to be specified. If 
neither of them is specified, or if both are specified, an error.fetch event 
must be thrown.\"

Proposed text:
\"\"

I think that this part of specification is in contradiction with section 
9.5.2: \"Document Initialization Errors\", which states: \"Errors that occur 
during documentation initialization (elements that occur in the CCXML 
document before <eventprocessor>) occur outside of CCXML\'s event handling 
mechanism. These errors MUST cause the CCXML thread of execution to 
terminate and notify the platform of the document error.\"

The element <meta> occurs in the CCXML document before <eventprocessor>, so 
it should be handled according to section 9.5.2.

Notes:

Related e-mails:

ISSUE-108 - PUBLIC - LCWD - Comments on CCXML Working Draft 19 January 2007 (2)

Tracker (W3C Member only):

ISSUE-108

Opened: 2007-02-08

Last Updated: 2009-11-19 10:56

State: CLOSED

Description:

http://lists.w3.org/Archives/Public/www-voice/2007JanMar/0032.html

From: Hrvoje Nezic <hrvoje.nezic@envox-lab.hr> 
Date: Wed, 7 Feb 2007 12:19:04 +0100
Message-ID: <005f01c74aa9$c718d3d0$1301a8c0@envox.local.hr> 
To: <www-voice@w3.org> 

9: Event handling

Current text:
\"If a semantic error occurs that prevents an element in the transition from 
being executed (such as the \'cond\' attribute of <if> being an invalid 
ECMAScript expression), then successive elements within that transition will 
NOT be executed; an error.semantic will be raised for the element that could 
not be executed. Note that elements that can be executed but that generate 
errors (such as a <disconnect> on an invalid connection ID) do not terminate 
execution of the transition.\"

I think that this explanation is not clear enough. The phrase \"elements that 
can be executed but that generate errors\" could be applied to most CCXML 
elements. I think that intention was probably to distinguish between 
synchronous and asynchronous elements. Synchronous elements are <var>, 
<assign>, <script>, <if>, <elseif>, <else>, <goto>, <exit>, <log>, while 
other elements are asynchronous and generate events to signal success or 
failure.

The new text could be something like this:
\"If a semantic error occurs that prevents a synchronous element in the 
transition from being executed (such as the \'cond\' attribute of <if> being 
an invalid ECMAScript expression), then successive elements within that 
transition will NOT be executed; an error.semantic will be raised for the 
element that could not be executed. If a semantic error occurs that prevents 
an asynchrounous element from being executed (such as a <disconnect> on an 
invalid connection ID), execution of the transition will not be terminated.\"

Notes:

Related e-mails:

ISSUE-109 - PUBLIC - LCWD - querry

Tracker (W3C Member only):

ISSUE-109

Opened: 2007-02-08

Last Updated: 2009-11-19 10:56

State: CLOSED

Description:

http://lists.w3.org/Archives/Public/www-voice/2007JanMar/0019.html

From: murulidhara <murulidharar@huawei.com> 
Date: Tue, 30 Jan 2007 12:34:35 +0530
To: www-voice@w3.org 
Message-id: <010401c7443c$e7046560$eb04120a@china.huawei.com> 
Hi,

 

When a dialog is started is it a necessary that it must be joined to some
connection or conference.

Suppose ,I start a dialog without preparing and in dialogstart connectionid
or conferenceid are not mentioned , and

Current event being processed is non connection event then what should be
the behavior of the CCXML interpreter.

Can dialogstart use the last processed connection event to get the
connectionid from it. if not what should be the behavior of CCXML
interpreter.

 

Regards,

murali

Notes:

Related e-mails:

ISSUE-110 - PUBLIC - LCWD - query.

Tracker (W3C Member only):

ISSUE-110

Opened: 2007-02-08

Last Updated: 2009-11-19 10:56

State: CLOSED

Description:

http://lists.w3.org/Archives/Public/www-voice/2007JanMar/0017.html

From: murulidhara <murulidharar@huawei.com> 
Date: Mon, 22 Jan 2007 17:25:01 +0530
To: www-voice@w3.org 
Message-id: <003301c73e1c$265c7b70$eb04120a@china.huawei.com> 
Hi,

 

I had a Query regarding the creation of bridges in case of implicit join to
a connection using <dialgprepare>

PROBLEM:

1.       create a session.

2.       create 2 connections say conn1 and conn2.

3.       preapare dialog x on conn1

4.       preapare dialog x on conn2

since the \"Implicit bridges created using <dialogprepare>/<dialogstart> (by
specifing \'connectionid\' or \'conferenceid\') are established when the dialog
is started. No bridging events are generated; the \'dialog.started\' event
indicates that the dialog was started and the bridge is in place.\"
Connection object will not be updated till dialog.started is received. And
so Connection objects of both conn1 and conn2 will not contain dialog id
which are just been prepared on them. Only session object will be updated.

 

So now.

Say conn1 gets connection.failed.

Now if I want to clear the dialog created on conn1 then I cant access
dialogid through event$.connection.dialogid  as connection object is not
updated.(dialog is not started still) , I cant even access it through
session variables. As session variable will intern access connection object.

And also session.dialogs[] , will give dialog id but they don\'t give to
which connection the dialog belongs.

So , how can I access the dialog id of conn1.

 

Please let me know.

 

Regards,

Murali dhar R

Notes:

Related e-mails:

ISSUE-111 - PUBLIC - CCXML

Tracker (W3C Member only):

ISSUE-111

Opened: 2007-02-08

Last Updated: 2009-12-13 09:15

State: CLOSED

Description:

http://lists.w3.org/Archives/Public/www-voice/2006OctDec/0109.html

CCXML \"event\" attribute in <move> element

This message: [ Message body ] [ Respond ] [ More options ]
Related messages: [ Next message ] [ Previous message ]
From: Hrvoje Nezic <hrvoje.nezic@envox-lab.hr> 
Date: Fri, 22 Dec 2006 17:30:38 +0100
Message-ID: <007501c725e6$83914530$1301a8c0@envox.local.hr> 
To: <www-voice@w3.org> 

Dear group,

I have a question about \"event\" attribute  in <move> element.

The specification says about this attribute:
\"The event source from which the event object originated, if any, must be 
moved to the target session. The event must also be sent to the target 
session to provide a notification.\"

If I understood it well, this event must be a connection or dialog event, 
like connection.alerting, connection.connected, dialog.started, etc:

<transition event=\"connection.connected\" name=\"evt\" >
     <move session_id=\"target_session_id\" event=\"evt\" />
     ...
</transition>

In the above case, the connection.connected event is handled, and it will be 
sent to another session to be handled again. This seems strange to me. When 
the above transition starts, the connection object will be in CONNECTED 
state.
Before the connection.connected event is being handled in another session, 
the object will be in wrong state, because according to the specification 
there is no transition from CONNECTED when current event is 
connection.connected.

Another problem is using evt.connection object in the same transition after 
<move>, while it is concurrently being moved to another session.

I would like to know if my understanding is correct.

Notes:

Related e-mails:

ISSUE-112 - PUBLIC - VXML-CCXML integration - Updating VoiceXML session variables

Tracker (W3C Member only):

ISSUE-112

Opened: 2007-02-08

Last Updated: 2009-12-13 09:16

State: CLOSED

Description:

http://lists.w3.org/Archives/Public/www-voice/2006OctDec/0072.html

From: Rajesh N <rajeshn@huawei.com> 
Date: Wed, 29 Nov 2006 19:41:21 +0530
To: www-voice@w3.org 
Message-id: <000001c713c0$3fbfa000$af04120a@china.huawei.com> 
Hi,
 
I have a query regarding the managment of VoiceXML session variables in the
context of VXML-CCXML integration.
 
CCXML 1.0 Appendix D.3 mentions that VoiceXML Session variables are updated
whenever there is a update to the associated connection or conference.
 
What are the scenario in which this can happen? Can someone provide any
examples? Also, which are the exact VXML standard session variables that can
be updated by CCXML?  Are they only the VXML session variables defined in
CCXML or do they also include the VXML 2.0 standard session variables?
 
Also, from the VXML interpreter\'s perspective, does it need to verify the
dialog session state, when CCXML requests a session variable updation.
According to the specifications, VXML session variables and any applicable
sub-properties are read-only. Does this mean that they are read-only only
for the VXML application or script?
 
Thanks
Rajesh
 
This e-mail and attachments contain confidential information from HUAWEI,
which is intended only for the person or entity whose address is listed
above. Any use of the information contained herein in any way (including,
but not limited to, total or partial disclosure, reproduction, or
dissemination) by persons other than the intended recipient\'s) is
prohibited. If you receive this e-mail in error, please notify the sender by
phone or email immediately and delete it!

Notes:

Related e-mails:

ISSUE-115 - LCWD - Comments from i18n core WG on CCXML

Tracker (W3C Member only):

ISSUE-115

Opened: 2007-02-08

Last Updated: 2009-12-13 09:17

State: CLOSED

Description:

http://lists.w3.org/Archives/Member/w3c-voice-wg/2007Jan/0100.html

From: Felix Sasaki <fsasaki@w3.org> 
Date: Sun, 28 Jan 2007 09:01:10 +0900
Message-ID: <45BBE7C6.3070409@w3.org> 
To: w3c-voice-wg@w3.org 
Cc: member-i18n-core@w3.org 

Hello VBWG,

The i18n core WG had filed comments on a previous version of the CCXML
draft , see http://www.w3.org/International/2005/05/ccxml1-0-review.html
. We had a response from you saying that you would look at the comments,
see http://lists.w3.org/Archives/Public/www-voice/2005JulSep/0015 .

However, we have not find any response. Could you point us to the
response or consider our original comments as LC comments for
http://www.w3.org/TR/2007/WD-ccxml-20070119/ ?

Thank you & regards, Felix.

Notes:

Related e-mails:

ISSUE-116 - LCWD - error.semantic/hints

Tracker (W3C Member only):

ISSUE-116

Opened: 2007-02-08

Last Updated: 2009-12-13 09:18

State: CLOSED

Description:

http://lists.w3.org/Archives/Member/w3c-voice-wg/2006Nov/0160.html

From: McGlashan, Scott <scott.mcglashan@hp.com> 
Date: Thu, 30 Nov 2006 18:34:35 +0100
Message-ID: <990C7D7B4096DC49B7BDB5D4F56E5B9F037CD054@sooexc02.emea.cpqcorp.net> 
To: \"RJ Auburn\" <rj@voxeo.com>, \"W3C Voice Browser Working Group\" <w3c-voice-wg@w3.org> 

One thing that has come up in the review is whether an error event can
be raised as a result of evaluating a hints object. Even though hints
evaluation itself is platform-specific, it seems reasonable to allow an
error event to be raised if the hints contents aren\'t supported or
conformant to the platform\'s model. 

Specific suggestion would be to add the following text to the
description of hints in each section. 

\"A platform MAY raise an error.semantic event if the information cannot
be processed by the implementation.\" 


Scott

Notes:

Related e-mails:

ISSUE-222 - PUBLIC - LCWD - Nagesh S-1 - Query in CCXML 1.0 Specification.

Tracker (W3C Member only):

ISSUE-222

Opened: 2007-04-30

Last Updated: 2009-12-13 09:18

State: CLOSED

Description:

Original Email: http://lists.w3.org/Archives/Public/www-voice/2007JanMar/0027.html
Thread: http://lists.w3.org/Archives/Public/www-voice/2007JanMar/thread.html#msg27 
Previous Issue: I-105
From: Nagesh S <nageshs@huawei.com> 
Date: Fri, 02 Feb 2007 11:17:04 +0530

Section: http://www.w3.org/TR/2007/WD-ccxml-20070119/#flowEventsErrorCreateCCXML

For the Event, error.createccxml in the section 6.3.8, the \"required\" field is not mentioned properly, it 
should be \"true\".

Notes:

Related e-mails:

ISSUE-223 - PUBLIC - LCWD - Nagesh S-2 - Query in CCXML 1.0 Specification.

Tracker (W3C Member only):

ISSUE-223

Opened: 2007-04-30

Last Updated: 2009-12-13 09:19

State: CLOSED

Description:

Original Email: http://lists.w3.org/Archives/Public/www-voice/2007JanMar/0027.html
Thread: http://lists.w3.org/Archives/Public/www-voice/2007JanMar/thread.html#msg27 
Previous Issue: I-105
From: Nagesh S <nageshs@huawei.com> 
Date: Fri, 02 Feb 2007 11:17:04 +0530


Section: http://www.w3.org/TR/2007/WD-ccxml-20070119/#s10.6.5 
see also sections on connection.redirected and connection.failed

In the events like error.move, error.send.failed, the reason attribute is a mandatory attribute but whereas 
for the event, connection.disconnected, connection.redirected, and connection.failed, the reason attribute 
is optional, is it intentional?

Notes:

Related e-mails:

ISSUE-224 - PUBLIC - LCWD - Nagesh S-3 - Query in CCXML 1.0 Specification.

Tracker (W3C Member only):

ISSUE-224

Opened: 2007-04-30

Last Updated: 2009-12-13 09:19

State: CLOSED

Description:

Original Email: http://lists.w3.org/Archives/Public/www-voice/2007JanMar/0027.html
Thread: http://lists.w3.org/Archives/Public/www-voice/2007JanMar/thread.html#msg27 
Previous Issue: I-105
From: Nagesh S <nageshs@huawei.com> 
Date: Fri, 02 Feb 2007 11:17:04 +0530

Section: http://www.w3.org/TR/2007/WD-ccxml-20070119/#Createcall

For the <createcall> element, attribute constraints missing for the attribute \"joinid\" and \"joindirection\", 
saying that the latter should be present if the former is present.

Notes:

Related e-mails:

ISSUE-225 - PUBLIC - LCWD - Nagesh S-4 - Query in CCXML 1.0 Specification.

Tracker (W3C Member only):

ISSUE-225

Opened: 2007-04-30

Last Updated: 2009-12-13 09:21

State: CLOSED

Description:

Original Email: http://lists.w3.org/Archives/Public/www-voice/2007JanMar/0027.html
Thread: http://lists.w3.org/Archives/Public/www-voice/2007JanMar/thread.html#msg27 
Previous Issue: I-105
From: Nagesh S <nageshs@huawei.com> 
Date: Fri, 02 Feb 2007 11:17:04 +0530

The DTD file present in the location, http://www.w3.org/TR/ccxml/ccxml.dtd. is not consistent with the 
element attributes mentioned in the specification. Eg: in the <send> element, the attribute data is 
removed but the DTD is not updated for the same, it is still reflecting data attribute.

Notes:

Related e-mails:

ISSUE-226 - PUBLIC - LCWD - Nagesh S-5 - Query in CCXML 1.0 Specification.

Tracker (W3C Member only):

ISSUE-226

Opened: 2007-04-30

Last Updated: 2009-12-13 09:22

State: CLOSED

Description:

Original Email: http://lists.w3.org/Archives/Public/www-voice/2007JanMar/0027.html
Thread: http://lists.w3.org/Archives/Public/www-voice/2007JanMar/thread.html#msg27 
Previous Issue: I-105
From: Nagesh S <nageshs@huawei.com> 
Date: Fri, 02 Feb 2007 11:17:04 +0530

Section: http://www.w3.org/TR/2007/WD-ccxml-20070119/#s10.2.5

The example given in the section, 10.2.5 does not reflect the new way of accessing the event attributes 
using the event$.

Notes:

Related e-mails:

ISSUE-227 - PUBLIC - LCWD - Nagesh S-6 - Query in CCXML 1.0 Specification.

Tracker (W3C Member only):

ISSUE-227

Opened: 2007-04-30

Last Updated: 2009-12-13 09:22

State: CLOSED

Description:

Original Email: http://lists.w3.org/Archives/Public/www-voice/2007JanMar/0027.html
Thread: http://lists.w3.org/Archives/Public/www-voice/2007JanMar/thread.html#msg27 
Previous Issue: I-105
From: Nagesh S <nageshs@huawei.com> 
Date: Fri, 02 Feb 2007 11:17:04 +0530

In the DTD file present in the location, http://www.w3.org/TR/ccxml/ccxml.dtd., xmlns attribute is not 
made a valid attribute for the element <ccxml> and <send> so the DTD validation of the valid CCXML 1.0 
complaint document fails when the xmlns attribute is present in the document.

Notes:

Related e-mails:

ISSUE-228 - PUBLIC - LCWD - Nagesh S-7 - Query in CCXML 1.0 Specification.

Tracker (W3C Member only):

ISSUE-228

Opened: 2007-04-30

Last Updated: 2009-12-13 09:23

State: CLOSED

Description:

Original Email: http://lists.w3.org/Archives/Public/www-voice/2007JanMar/0027.html
Thread: http://lists.w3.org/Archives/Public/www-voice/2007JanMar/thread.html#msg27 
Previous Issue: I-105
From: Nagesh S <nageshs@huawei.com> 
Date: Fri, 02 Feb 2007 11:17:04 +0530

Section: http://www.w3.org/TR/2007/WD-ccxml-20070119/#s10.2.1

The connection state diagram provided in the section 10.2.1, the connection state transition from 
ALERTING to FAILED, can happen because of the \"connection.rejected\" event, but the same is not present 
in the specification. My doubt is when the state of the connection transitions to FAILED state after issuing 
the <reject> command.

Notes:

Related e-mails:

ISSUE-229 - PUBLIC - LCWD - Sajeesh-1 [CCXML] Query regarding <dialogstart> command

Tracker (W3C Member only):

ISSUE-229

Opened: 2007-04-30

Last Updated: 2009-12-13 09:02

State: CLOSED

Description:

Original Email: http://lists.w3.org/Archives/Public/www-voice/2007JanMar/0028.html
Thread: http://lists.w3.org/Archives/Public/www-voice/2007JanMar/thread.html#msg28
Previous Issue: I-106
From: Sajeesh <sajeeshs@huawei.com> 
Date: Sat, 03 Feb 2007 12:59:17 +0530

Section: http://www.w3.org/TR/2007/WD-ccxml-20070119/#dialogprepare


\"If the prepareddialogid attribute is specified and any attribute values conflict with the values specified 
in the <dialogprepare> element this MUST result in the throwing of an error.dialog.notstarted event\"

In this case, should we check all attributes of <dialogstart> like connectionid/conferenceid, maxage, 
maxstale, enctype, method and hints against the corresponding <dialogprepare> command?

Or only the checking of mediadiection (which is explicitly specified in CCXML draft) is enough?

Notes:

Related e-mails:

ISSUE-230 - PUBLIC - LCWD - Nezic-1 - Comments on CCXML Working Draft 19 January 2007

Tracker (W3C Member only):

ISSUE-230

Opened: 2007-04-30

Last Updated: 2009-12-13 09:26

State: CLOSED

Description:

Original Email: http://lists.w3.org/Archives/Public/www-voice/2007JanMar/0030.html
Thread: http://lists.w3.org/Archives/Public/www-voice/2007JanMar/thread.html#msg30
Previous Issue: I-107
Subject: Comments on CCXML Working Draft 19 January 2007
From: Hrvoje Nezic <hrvoje.nezic@envox-lab.hr> 
Date: Tue, 6 Feb 2007 18:08:51 +0100

Section: http://www.w3.org/TR/2007/WD-ccxml-20070119/#Fetch

6.2.7: <fetch>

Current text: \"The event is one of fetch.done, which indicates that the identified content was fetched 
successfully, or error.fetch, indicative of a failure to fetch the requested content.\"

Proposed text: \"The event is one of fetch.done, which indicates that the identified content was fetched 
successfully and in case of CCXML document, XML parsing / validation was performed, or error.fetch, 
indicative of a failure to fetch the requested content. \"

It is not quite clear from the description of <fetch> what the CCXML interpreter should perform before 
its sends the fetch.done event.

Notes:

Related e-mails:

ISSUE-231 - PUBLIC - LCWD - Nezic-2 - Comments on CCXML Working Draft 19 January 2007

Tracker (W3C Member only):

ISSUE-231

Opened: 2007-04-30

Last Updated: 2009-12-13 09:27

State: CLOSED

Description:

Original Email: http://lists.w3.org/Archives/Public/www-voice/2007JanMar/0030.html
Thread: http://lists.w3.org/Archives/Public/www-voice/2007JanMar/thread.html#msg30
Previous Issue: I-107
Subject: Comments on CCXML Working Draft 19 January 2007
From: Hrvoje Nezic <hrvoje.nezic@envox-lab.hr> 
Date: Tue, 6 Feb 2007 18:08:51 +0100

Section: http://www.w3.org/TR/2007/WD-ccxml-20070119/#Meta

6.2.2.2: <meta> Attribute Details

Current text: \" Either the name or the http-equiv attribute has to be specified. If neither of them is 
specified, or if both are specified, an
error.fetch event must be thrown.\"

Proposed text: \"\"

I think that this part of specification is in contradiction with section 9.5.2: \"Document Initialization 
Errors\", which states: \"Errors that occur during documentation initialization (elements that occur in the 
CCXML document before <eventprocessor>) occur outside of CCXML\'s event handling mechanism. 
These errors MUST cause the CCXML thread of execution to terminate and notify the platform of the 
document error.\"

The element <meta> occurs in the CCXML document before <eventprocessor>, so it should be handled 
according to section 9.5.2.

Notes:

Related e-mails:

ISSUE-232 - PUBLIC - LCWD - Nezic-3 - Comments on CCXML Working Draft 19 January 2007 (2)

Tracker (W3C Member only):

ISSUE-232

Opened: 2007-04-30

Last Updated: 2009-12-13 09:27

State: CLOSED

Description:

Original Email: http://lists.w3.org/Archives/Public/www-voice/2007JanMar/0032.html
Thread: http://lists.w3.org/Archives/Public/www-voice/2007JanMar/thread.html#msg32
Previous Issue: I-108
From: Hrvoje Nezic <hrvoje.nezic@envox-lab.hr> 
Date: Wed, 7 Feb 2007 12:19:04 +0100

Section: http://www.w3.org/TR/2007/WD-ccxml-20070119/#event-handling

9: Event handling

Current text:
\"If a semantic error occurs that prevents an element in the transition from being executed (such as the 
\'cond\' attribute of <if> being an invalid ECMAScript expression), then successive elements within that 
transition will NOT be executed; an error.semantic will be raised for the element that could not be 
executed. Note that elements that can be executed but that generate errors (such as a <disconnect> on 
an invalid connection ID) do not terminate execution of the transition.\"

I think that this explanation is not clear enough. The phrase \"elements that can be executed but that 
generate errors\" could be applied to most CCXML elements. I think that intention was probably to 
distinguish between synchronous and asynchronous elements. Synchronous elements are <var>, 
<assign>, <script>, <if>, <elseif>, <else>, <goto>, <exit>, <log>, while other elements are 
asynchronous and generate events to signal success or failure.

The new text could be something like this: \"If a semantic error occurs that prevents a synchronous 
element in the transition from being executed (such as the \'cond\' attribute of <if> being an invalid 
ECMAScript expression), then successive elements within that transition will NOT be executed; an 
error.semantic will be raised for the element that could not be executed. If a semantic error occurs that 
prevents an asynchrounous element from being executed (such as a <disconnect> on an invalid 
connection ID), execution of the transition will not be terminated.\"

Notes:

Related e-mails:

ISSUE-233 - PUBLIC - LCWD - murulidhara-1 - querry

Tracker (W3C Member only):

ISSUE-233

Opened: 2007-04-30

Last Updated: 2009-12-13 09:28

State: CLOSED

Description:

Original Email: http://lists.w3.org/Archives/Public/www-voice/2007JanMar/0019.html
Thread: http://lists.w3.org/Archives/Public/www-voice/2007JanMar/thread.html#msg19
Previous Issue: I-109
Subject: querry
From: murulidhara <murulidharar@huawei.com> 
Date: Tue, 30 Jan 2007 12:34:35 +0530

When a dialog is started is it a necessary that it must be joined to some connection or conference.

Suppose ,I start a dialog without preparing and in dialogstart connectionid or conferenceid are not 
mentioned , and

Current event being processed is non connection event then what should be the behavior of the CCXML 
interpreter.

Can dialogstart use the last processed connection event to get the connectionid from it. if not what 
should be the behavior of CCXML interpreter.

Notes:

Related e-mails:

ISSUE-234 - PUBLIC - LCWD - murulidhara-2 - query.

Tracker (W3C Member only):

ISSUE-234

Opened: 2007-04-30

Last Updated: 2009-12-13 09:32

State: CLOSED

Description:

Original Email: http://lists.w3.org/Archives/Public/www-voice/2007JanMar/0017.html
Thread: http://lists.w3.org/Archives/Public/www-voice/2007JanMar/thread.html#msg17
Previous Issue: I-110
Subject: query.
From: murulidhara <murulidharar@huawei.com> 
Date: Mon, 22 Jan 2007 17:25:01 +0530

I had a Query regarding the creation of bridges in case of implicit join to a connection using 
<dialgprepare>

PROBLEM:

1.       create a session.

2.       create 2 connections say conn1 and conn2.

3.       preapare dialog x on conn1

4.       preapare dialog x on conn2

since the \"Implicit bridges created using <dialogprepare>/<dialogstart> (by specifing \'connectionid\' or 
\'conferenceid\') are established when the dialog is started. No bridging events are generated; the 
\'dialog.started\' event indicates that the dialog was started and the bridge is in place.\" Connection object 
will not be updated till dialog.started is received. And so Connection objects of both conn1 and conn2 
will not contain dialog id which are just been prepared on them. Only session object will be updated.

 

So now.

Say conn1 gets connection.failed.

Now if I want to clear the dialog created on conn1 then I cant access dialogid through event
$.connection.dialogid  as connection object is not updated.(dialog is not started still) , I cant even 
access it through session variables. As session variable will intern access connection object.

And also session.dialogs[] , will give dialog id but they don\'t give to which connection the dialog 
belongs.

So , how can I access the dialog id of conn1.

Notes:

Related e-mails:

ISSUE-235 - PUBLIC - LCWD - murulidhara-3 - CCXML : Query regarding error.semantic

Tracker (W3C Member only):

ISSUE-235

Opened: 2007-04-30

Last Updated: 2009-12-13 09:32

State: CLOSED

Description:

Original Email: http://lists.w3.org/Archives/Public/www-voice/2007AprJun/0000.html
Thread: http://lists.w3.org/Archives/Public/www-voice/2007AprJun/thread.html#msg0
Previous Issue: none
From: murulidhara <murulidharar@huawei.com> 
Date: Tue, 03 Apr 2007 17:35:57 +0530

Section: http://www.w3.org/TR/2007/WD-ccxml-20070119/#varelements


Currently Spec Says

\"It is illegal to make an assignment to a variable that has not been explicitly declared using <var> or a 
var statement within a <script>. Attempting to assign to an undeclared variable causes an 
error.semantic event to be thrown.\"

But , is this applicable to accessing also :

For ex:

<log expr =\"varable_1\"/>

variable_1 is not declared in entire document.

And log won\'t modify or assign value to variable_1.

Does this cause error.semantic to be thrown by interpreter. Currently spec does not say accessing must 
result in throwing error.semantic.

One more typical example will be :

Accessing an optional attribute in an event. Using event$.optinal_attribute_name , does interpreter 
throw error.semantic if optinal_attribute_name is not set while throwing event to ccxml interpreter.

Notes:

Related e-mails:

ISSUE-236 - PUBLIC - LCWD - Kuba-1 - CCXML: Dialog and Connection objects

Tracker (W3C Member only):

ISSUE-236

Opened: 2007-04-30

Last Updated: 2009-12-13 09:33

State: CLOSED

Description:

Original Email: http://lists.w3.org/Archives/Public/www-voice/2007JanMar/0076.html
Thread: http://lists.w3.org/Archives/Public/www-voice/2007JanMar/thread.html#msg76
Previous Issue: none
Subject: CCXML: Dialog and Connection objects
From: Petr Kuba <kuba@optimsys.cz> 
Date: Thu, 15 Mar 2007 11:55:32 +0100

Section: http://www.w3.org/TR/2007/WD-ccxml-20070119/#dialog_class

Dialog object contains connectionid and/or conferenceid properties which identify the connection/
conference that is driving a media stream to the dialog.

As we understand, after introducing input and outputs properties in the last draft connectionid/
conferenceid will always have the same value as the input property. Therefore the only information 
connectionid/conferenceid properties bring is the type of endpoint. These properties do not seem to be 
very useful any more. Is this correct or do we miss anything?

Notes:

Related e-mails:

ISSUE-237 - PUBLIC - LCWD - Kuba-2 - CCXML: Dialog and Connection objects

Tracker (W3C Member only):

ISSUE-237

Opened: 2007-04-30

Last Updated: 2009-12-13 09:34

State: CLOSED

Description:

Original Email: http://lists.w3.org/Archives/Public/www-voice/2007JanMar/0076.html
Thread: http://lists.w3.org/Archives/Public/www-voice/2007JanMar/thread.html#msg76
Previous Issue: none
Subject: CCXML: Dialog and Connection objects
From: Petr Kuba <kuba@optimsys.cz> 
Date: Thu, 15 Mar 2007 11:55:32 +0100

Section: http://www.w3.org/TR/2007/WD-ccxml-20070119/#connection.properties

Analogously, Connection object contains a dialogid property. Its definition states: \"This property is the 
identifier of an associated dialog, if there is one currently using the connection.\" What does \"associated 
dialog\" mean? What if there are more dialogs joined to the connection? If this property identifies the 
dialog that is driving a media stream to the connection (which seems to be more logical interpretation) 
then it again has always the same value as the input property and we do not find it very useful.

Notes:

Related e-mails:

ISSUE-238 - PUBLIC - LCWD - Sajeesh-2 [CCXML]Regarding namelist attribute

Tracker (W3C Member only):

ISSUE-238

Opened: 2007-04-30

Last Updated: 2009-12-13 09:35

State: CLOSED

Description:

Original Email: http://lists.w3.org/Archives/Public/www-voice/2007AprJun/0028.html
Thread: http://lists.w3.org/Archives/Public/www-voice/2007AprJun/thread.html#msg28
Previous Issue: none
Subject: [CCXML]Regarding namelist attribute
From: Sajeesh <sajeeshs@huawei.com> 
Date: Fri, 20 Apr 2007 11:10:53 +0530

Section: http://www.w3.org/TR/2007/WD-ccxml-20070119/#dialogstart
Section: http://www.w3.org/TR/2007/WD-ccxml-20070119/#Fetch

In CCXML draft, for the namelist attribute, the description is differenct for some elments. For 
<dialogstart>, <dialogprepare>, <exit>- the description says that \"A list of ONE or more white space 
separated variable names..\" And for other elements like <fetch>, <createccxml>, <send>, the 
description says \"A list of ZERO or more white space separated variable names..\" Is it a typo in the 
CCXML draft or is it for some special handling ? What is the purpose of a namelist which contains no 
variable names?

Notes:

Related e-mails:

ISSUE-325 - PUBLIC - CCXML state variable

Tracker (W3C Member only):

ISSUE-325

Opened: 2008-01-31

Last Updated: 2009-12-13 09:35

State: CLOSED

Description:

	Resent-From: 	www-voice@w3.org
	From: 	yakulis@avaya.com
	Subject: 	CCXML state variable
	Date: 	January 24, 2008 4:44:17 PM EST
	To: 	www-voice@w3.org

Since the event attribute was removed in the last revision of the CCXML spec, it follows (to me) that the state variable should be implicitly defined at state$ and the attribute statevariable removed from eventprocessor?

Ross Yakulis

Notes:

Related e-mails:

ISSUE-524 - PUBLIC - <disconnect/> on outbound call

Tracker (W3C Member only):

ISSUE-524

Opened: 2008-07-17

Last Updated: 2009-12-13 09:36

State: RAISED

Description:

	Resent-From: 	www-voice@w3.org
	From: 	rethishkumarps@huawei.com
	Subject: 	<disconnect/> on outbound call
	Date: 	May 13, 2008 3:40:59 AM EDT
	To: 	www-voice@w3.org
	Cc: 	ranjit@huawei.com
	Reply-To: 	rethishkumarps@huawei.com
Hi,
 I find some ambiguity in the CCXML specification regarding the nature of <disconnect/> handling while an outbound call is in progress.
 
10.2.1: Connection State:
    The figure illustrates that a connection.disconnected in PROGRESSING state transitions to FAILED state.
    But, the table below this mentions that a connection.disconnected is received for an outbound call in progress when the <createcall> request was abandoned at the request of the application (using <disconnect>). "The Connection Object transitions to the DISCONNECTED state."
 
Is there any other case where a connection.disconnected can be received while an outbound call is in progress that would lead to FAILED state?
 
10.5.9: <disconnect> mentions:
A CCXML document may use <disconnect> to abandon an outbound connection created using <createcall> which has not yet entered the CONNECTED state. ﾒ If <disconnect> is used to abandon an outbound call, it results in the generation of a 'connection.failed' event.ﾓ
 
IMHO the handling of <disconnect/> contradicts each other in the two sections. Please let me know your opinion on this.
Thanks & regards
Rethish

Notes:

Related e-mails:

ISSUE-525 - PUBLIC - Notification of implicit bridge teardowns

Tracker (W3C Member only):

ISSUE-525

Opened: 2008-07-17

Last Updated: 2009-12-13 09:36

State: CLOSED

Description:

	Resent-From: 	www-voice@w3.org
	From: 	dsanders@avaya.com
	Subject: 	Notification of implicit bridge teardowns
	Date: 	May 30, 2008 1:23:01 PM EDT
	To: 	www-voice@w3.org
 
The January 19th, 2007 CCXML Working Draft is not very clear on how implicit bridge teardowns resulting from a <join> should be handled.  Section 10.4.1 shows all of the possible outcomes of a <join> tag.  Some of these examples require a full or partial teardown of an existing bridge.  The spec does not state if a ﾔconference.unjoinedﾕ event should be generated when this occurs.  It does state in section 10.6.14 that if a connection is dropped (as in a merge, disconnect, etc.), then the appropriate ﾔconference.unjoinedﾕ event(s) should be sent.  It may be an easy assumption that ANY implicit bridge teardowns should result in a ﾔconference.unjoinedﾕ event, but what about partial teardowns?  It starts to get a little more complicated there.  Is it enough to just update the connection state variables when bridges change as a result of a <join>?
 
Thanks,
-Derek Sanders

Notes:

Related e-mails:

ISSUE-553 - PUBLIC - Incorrect example in the CCXML spec

Tracker (W3C Member only):

ISSUE-553

Opened: 2008-11-13

Last Updated: 2009-12-13 09:37

State: CLOSED

Description:

	Resent-From: 	www-voice@w3.org
	From: 	kuba@optimsys.cz
	Subject: 	Incorrect example in the CCXML spec
	Date: 	November 13, 2008 7:19:53 AM EST
	To: 	www-voice@w3.org

Dear WBWG,

It seems that there is an incorrect example in the CCXML specification.
The problem is on the very last line in Section 10.5.4.3 in the hints
attribute of the <createcall> tag:
hints="{callingDevice: 'notSpecified', callCharacteristics: 'voiceUnitCall'}"

When we tried to interpret a similar <createcall> using our OptimTalk CCXML interpreter, we received the following ECMAScript error:
"SyntaxError: invalid label"

We looked at the ECMAScript formal grammar in the ECMAScript specification and found out that reporting an error when evaluating the
"{callingDevice: 'notSpecified', callCharacteristics: 'voiceUnitCall'}"
script is a correct behavior.

Following the ECMAScript formal grammar, the script is an expression
statement and the ECMAScript spec says:

<CITATION>
12.4 Expression Statement

ExpressionStatement :
[lookahead ? {{, function}] Expression ;

Note that an ExpressionStatement cannot start with an opening curly brace
because that might make it ambiguous with a Block. [...]
</CITATION>

A solution is to use the hints attribute as follows:
hints="var tmp = {callingDevice: 'notSpecified', callCharacteristics: 'voiceUnitCall'}; tmp"

Can you please correct the specification?

Regards,
Petr Kuba

-- 
  Petr Kuba, Project Manager
  OptimSys, s.r.o
  kuba@optimsys.cz
  Tel: +420 541 143 065
  Fax: +420 541 143 066
  http://www.optimsys.cz

Notes:

Related e-mails:

ISSUE-569 - PUBLIC - posting ccxml.exit to parent upon child getting a ccxml.kill event

Tracker (W3C Member only):

ISSUE-569

Opened: 2009-02-12

Last Updated: 2009-12-13 09:37

State: CLOSED

Description:

	Resent-From: 	www-voice@w3.org
	From: 	rajeshn@huawei.com
	Subject: 	Regarding posting ccxml.exit to parent upon child getting a ccxml.kill  event
	Date: 	February 9, 2009 9:03:02 PM EST
	To: 	www-voice@w3.org
	Reply-To: 	rajeshn@huawei.com
Hi,
 
I have a doubt regarding the ccxml.exit event posted to the parent session when the child session ends.
 
The spec says.. "This event is generated when a CCXML document executes an <exit>, having an unhandled "error.*" or ccxml.kill event"
 
From my interpretation of this sentence and the subsequent explantion of the "reason" attribute, I find three possibilities for child session to terminate:
 
a) Child session encounters an <exit> element in any transition (normal event / error event / kill event)
b) Child session recieves an(y) error event (error.*), but there is no transition to handle it.
c) Child session recieves a ccxml.kill event.
 
My doubt is regarding option (c) above. There are 3 sub-possibilities for this case:
 
(i) Child session has a transition to handle to ccxml.kill event and the transition also has an <exit> element. Event handling results in the processing of <exit>.
(ii) Child session has a transition to handle to ccxml.kill event, BUT the transition DOES NOT have an <exit> element.
(iii) Child session DOES NOT have a transition for ccxml.kill event
 
The child session should terminate in all these cases. Should ccxml.exit be posted to parent session in all these cases?
 
The basic reason for this doubt  is a small level of ambiguity associated with the phrase "having an unhandled "error.*" or ccxml.kill event". Does the "unhandled" apply to only error.* or both error.* and ccxml.kill?
 
Please clarify.
 
Thanks
Rajesh

Notes:

Related e-mails:

ISSUE-570 - PUBLIC - CCXML WD 19012007 - Limiting amount of connection inputs and other comments

Tracker (W3C Member only):

ISSUE-570

Opened: 2009-02-19

Last Updated: 2009-12-13 09:40

State: CLOSED

Description:

	Resent-From: 	www-voice@w3.org
	From: 	Teemu.Tingander@tecnomen.com
	Subject: 	CCXML WD 19012007 - Limiting amount of connection inputs and other comments.
	Date: 	February 17, 2009 4:55:04 AM EST
	To: 	www-voice@w3.org

Dear WBWG
 
I have found few issues in current CCXML working draft  that I would like to have clarified or reasoned. Iﾕm not currently working with  CCXML interpreter so unfortunately my comments do not cover the whole document.
 
1.       <join/> - Limiting inputs to only one is not well reasoned. There seems to be no good reason for limiting connection objects input to only one. If platform is capable of ﾒmixingﾓ input the specification should not disallow this. When media ﾒsplittingﾓ is allowed with outputs the mixing of input should be equally allowed, taking in account the systems capabilities.
a.       For example a Connection that is joined to conference and system wants to play audio periodically to caller. This should be allowed without leaving conference. Conference object joined with dialog is capable of doing this why should the connection object be more limited.
b.      Limiting inputs to only one as in current WD, causes <join/> command to tear down some bridges or change their duplex without explicit request to do so. I think that this automation is confusing. If system does not support multiple inputs and <join/> request would cause that happen, the <join/> request should fail with error event.
c.       If this limitation is removed the complex  automation logic defined in chapters 10.4.1 and 10.4.2  would be obsolete
d.      The clause in chapter 10.4. ﾒNote that <join> MUST NOT be used to add a Connection to an existing two-party bridge in order to create a 3-way Conference Insteadﾓ does not make any sense.
                                                               i.      In current scenario  proposed in current specification, A would hear C and  C would hear A , but B would only hear A without ablity to speak to A (the outcome of fullduplex , <join id1=ﾓaﾓ id1=ﾓbﾓ />  and <join id1=ﾓaﾓ id2=ﾓcﾓ />).  
                                                             ii.      Without limiting inputs to 1  and as special case 3 party network style conferencing could be achieved with full duplex joins , <join id1=ﾓaﾓ id1=ﾓbﾓ />  and <join id1=ﾓaﾓ id2=ﾓcﾓ /> and <join id1=ﾓbﾓ id2=ﾓcﾓ/>. On the long run, this is not very efficient way of conferencing and specification could make this opinion know but should retain from making it non-conformant.
e.      If the system is capable of capturing input ( for example ﾒDTMFSﾓ)  to one dialog form multiple connections, why to rule out this possibility even thou it might be quite uncommon.
2.       7.3.2 <dialogterminate/> - At just end of chapter, Current WD states ﾒThe platform MUST implicitly tear down any existing bridges to the dialog and send a conference.unjoined to the CCXML document once the media paths have been freed.ﾓ  This clause should only match explicit bridges to dialogs, as defined in 10.4. This should be defined in specification more clearly, unless,  In context of <dialogstart/> and <dialogprepare/> and the definition of Implicit bridges in chapter 10.4, sending conference.unjoined does not follow the line.
 
 
BR
-          Teemu

Notes:

Related e-mails:

ISSUE-614 - PUBLIC - Reg execution of subsequent elements after an event is encountered for current element in <transition>

Tracker (W3C Member only):

ISSUE-614

Opened: 2009-07-16

Last Updated: 2009-12-13 09:40

State: CLOSED

Description:

	Resent-From: 	www-voice@w3.org
	From: 	rajeshn@huawei.com
	Subject: 	[CCXML] Reg execution of subsequent elements after an event is  encountered for current element in <transition>
	Date: 	July 2, 2009 9:25:17 AM EDT
	To: 	www-voice@w3.org

Hi,
 
I have a doubt regarding the continuation of processing of subsequent elements in a <transition>, after one of the elements has encountered an error.
 
Example:
<transition event=ﾓconnection.connectedﾓ>
    <log expr=ﾓﾕIn transition for connection.connected eventﾕﾓ/>
    <dialogstart src=ﾓBAD_ECMA_EXPRﾓ />
    <assign name=ﾓstate0ﾓ expr=ﾓﾕdialog_Activeﾕﾓ/>                                  //assume state0 is the state variable
</transition>
 
In this case, evaluation of ﾒsrcﾓ attribute for <dialogstart> leads to an error.semantic event. Once the interpreter posts this event, should it continue to execute the next element <assign> in the transition?
 
I felt that the paragraph describing the ﾒcontinue / do not continueﾓ part for event handling in the CCXML specification was a bit ambiguous. (Section 9.1 Overview ﾐ event handling). As per my understanding, the interpreter should not execute the next element in situations like (a) if the evaluation of an attribute of the current element fails or (b) if the interpreter fails in any of its internal processing related to the current element.
 
The above given snippet is an example of (a).  An example of situation (b) could be say, if <accept> tag is encountered when the connection state is not ALERTING (ex: in a transition for connection.connected) ﾐ This may lead to interpreter posting error.connection.wrongstate event
 
I think it may be more clearly described in the specification as to, under which all conditions shall the interpreter continue to execute subsequent elements. Is it that the interpreter can continue to execute next element if it is able to process all attributes of the current element without error and perform the necessary actions to request the platform to realize the required operation?
 
Thanks
Rajesh

Notes:

Related e-mails:

ISSUE-633 - PUBLIC - using Object in the application scope - example error

Tracker (W3C Member only):

ISSUE-633

Opened: 2009-10-22

Last Updated: 2009-12-13 09:41

State: CLOSED

Description:

	Resent-From: 	www-voice@w3.org
	From: 	Petr Kuba <kuba@optimsys.cz>
	Subject: 	CCXML: using Object in the application scope - example error
	Date: 	September 30, 2009 3:01:15 PM GMT+02:00
	To: 	www-voice@w3.org


Hello,

We believe that there is an error in the CCXML specification, section 8.4.

The example in this section shows how to create an Object in the application scope:

 <var name="application.obj" expr="new Object()"/>

We assume that behavior of the <var> tag should be the same as behaviour  of a var statement within a <script> (although it is not explicitly stated in the specification). However, the following statement is not allowed in ECMAScript:

 var application.obj = new Object();

However, it is correct to use the the following statement in ECMAScript:

 application.obj = new Object();

Therefore we believe that correct version of the CCXML example is:

 <assign name="application.obj" expr="new Object()"/>

In this case, the description above the example should be clarified as well.

Thanks for response,

Petr Kuba


-- 
  Petr Kuba, Project Manager
  OptimSys, s.r.o
  kuba@optimsys.cz
  Tel: +420 541 143 065
  Fax: +420 541 143 066
  http://www.optimsys.cz

Notes:

Related e-mails:

ISSUE-637 - PUBLIC - Comments on CCXML specification - Attribute 'info' in the conference.created and conference.destroyed events

Tracker (W3C Member only):

ISSUE-637

Opened: 2009-10-22

Last Updated: 2009-12-13 09:29

State: CLOSED

Description:

From: http://lists.w3.org/Archives/Public/www-voice/2009JulSep/0019.html

	Resent-From: 	www-voice@w3.org
	From: 	Petr Kuba <kuba@optimsys.cz>
	Subject: 	Comments on CCXML specification
	Date: 	September 18, 2009 11:57:02 AM GMT+02:00
	To: 	www-voice@w3.org


3) Attribute 'info' in the conference.created and conference.destroyed events

Our idea to work around the problem (2) [ ISSUE-636 ] was to use the platform dependent attribute 'info' in the conference.created event. However, in contrast to the connection.* events there is no such attribute in conference.created nor conference.destroyed events. Is there any reason for this?

Our suggestion is to add attribute 'info' to the conference.created and conference.destroyed events with the same meaning this attribute has in connection.* events.

Notes:

Related e-mails: