- From: Petr Kuba <kuba@optimsys.cz>
- Date: Thu, 16 Sep 2010 08:41:10 +0200
- To: RJ Auburn <rj@voxeo.com>
- CC: www-voice <www-voice@w3.org>
RJ, This resolution is perfect from my point of view. Thanks, Petr On 16.9.2010 5:17, RJ Auburn wrote: > 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| event/MUST/ 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 06:41:57 UTC