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

Re: April CCXML: attribute 'id' of the error.notallowed event - ISSUE-707 [cc]

From: RJ Auburn <rj@voxeo.com>
Date: Wed, 15 Sep 2010 23:17:07 -0400
Cc: www-voice <www-voice@w3.org>, W3C Voice Browser Working Group <w3c-voice-wg@w3.org>
Message-Id: <DB54DFE8-1AD6-48AA-B1E1-D57E97A72460@voxeo.com>
To: Petr Kuba <kuba@optimsys.cz>
Petr:

We have accepted this change. The section 9.2.5.1 now reads: 
The cancel operation cancels a pending event by removing it from the delayed event queue of the CCXML session that initiated the <send>, preventing it from ever being delivered. If the delay has expired and the event has already been removed from the delayed event queue, the <cancel> request MUST fail and an error.notallowed eventMUST be delivered to the event queue of the CCXML session that executed the <cancel> with the id property populated with the sendid of the event that the <cancel> was requested for. Otherwise, a cancel.successful event MUST be delivered to indicate that the <cancel> was successful, and that the cancelled event was not delivered. Sessions are only permitted to cancel their own delayed events; they may not cancel the delayed events of other sessions.


The id attribute of section 9.3.1 (error.noallowed) now reads:

The ID, if specified in the element being executed, of the affected connection, dialog, session, event, or conference.

Please let us know if you have any further comments, otherwise we will go on and close out this issue. 

Best regards,

	RJ


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



On Jun 3, 2010, at 8:18 AM, RJ Auburn wrote:

> Petr:
> 
> This is tracked as ISSUE-707. 
> 
> ---
> RJ Auburn
> CTO, Voxeo Corporation
> tel:+1-407-418-1800
> 
> Come join us at our Voxeo Customer Summit
> June 21st  June 23rd at the Hard Rock Hotel
> Register today for your All Access Pass:  
> http://www.voxeo.com/summits/customer
> 
> 
> 
> 
> On May 5, 2010, at 11:03 AM, Petr Kuba wrote:
> 
>> Hello,
>> 
>> Usage of the error.notallowed event in the <cancel> element should be probably clarified.
>> 
>> Overview of the <cancel> element in 9.2.5.1 states:
>> 
>>   ...the <cancel> request MUST fail and an error.notallowed event
>>   MUST be delivered to the event queue...
>> 
>> Description of the 'id' attribute of the error.notallowed event states:
>> 
>>   The ID, if specified in the element being executed, of the affected
>>   connection, dialog, session, or conference.
>> 
>> The question is: shall the 'id' attribute of the error.notallowed event contain id of the event for which <cancel> failed? If yes, it should be explicitly stated in 9.2.5.1 and description of the 'id' attribute of the error.notallowed event should list also event (besides connection, session and others).
>> 
>> 
>> Thanks,
>> 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
>> 
> 
Received on Thursday, 16 September 2010 03:17:42 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Thursday, 16 September 2010 03:17:48 GMT