Re: April CCXML, 7_2: combination of attributes in <dialogstart> - ISSUE-724

Petr,

This did indeed get missed the first time around. Thanks for resending. 

Tracker ID is ISSUE-724. 

	RJ

On Jul 19, 2010, at 9:59 AM, Petr Kuba wrote:

> Hello www-voice,
> 
> We haven't received any response to this issue. Could you please look into this because it's blocking us in the new Implementation Report.
> 
> Thanks,
> Petr
> 
> On 27.5.2010 17:29, Petr Kuba wrote:
>> Hello www-voice,
>> 
>> In 7_2.txml, assertions 340, 342, 347, 349, 366, 368, 370, 373, and 1186
>> test the following features in <dialogstart>:
>> 
>> (1) The src, type, namelist, maxage, maxstale, enctype, method, and
>> parameters attributes MUST NOT be specified in conjunction with the
>> prepareddialogid attribute.
>> 
>> (2) 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.
>> 
>> ------
>> 
>> We believe that the incorrect combination of mutually exclusive
>> attributes in (1) should be handled according to 9.5.1 Fetching &
>> compilation errors:
>> 
>> "Errors that occur in trying to load and compile a CCXML document, such
>> as ... validation errors (Including checks for mutually exclusive
>> attributes...)"
>> 
>> Therefore these errors should result in error.createccxml or error.fetch
>> instead of error.dialog.notstarted.
>> 
>> ------
>> 
>> Thus (2) could apply only on the connectionid and conferenceid
>> attributes. However, the Specification states in description of these
>> attributes:
>> 
>> "If the dialog was previously prepared using a <dialogprepare> element
>> with a connectionid or conferenceid specified, and this attribute is
>> also specified, execution of the <dialogstart> MUST fail with an
>> error.dialog.notstarted event."
>> 
>> Therefore the conflict in (2) cannot occur because it is not allowed to
>> use connectionid / conferenceid in both <dialogprepare> and <dialogstart>.
>> 
>> We recommend to remove the statement (2) from the specification (Section
>> 7.2.2.1, paragraph 4).
>> 
>> 
>> Thanks,
>> Petr
>> 
> 

Received on Thursday, 29 July 2010 14:15:32 UTC