- From: RJ Auburn <rj@voxeo.com>
- Date: Wed, 15 Sep 2010 23:17:07 -0400
- To: Petr Kuba <kuba@optimsys.cz>
- 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>
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 UTC