- From: RJ Auburn <rj@voxeo.com>
- Date: Thu, 8 Feb 2007 10:14:19 -0500
- To: RJ Auburn <rj@voxeo.com>
- Cc: Nagesh S <nageshs@huawei.com>, www-voice@w3.org
Nagesh: for your reference this is being tracked as ISSUE-105 RJ --- RJ Auburn CTO, Voxeo Corporation tel:+1-407-418-1800 On Feb 7, 2007, at 7:50 AM, RJ Auburn wrote: > > Nagesh: > > Thanks for these comments. The working group will form a reply to > your issues very shortly. > > Regards: > > RJ > > --- > RJ Auburn > CTO, Voxeo Corporation > tel:+1-407-418-1800 > > > > On Feb 2, 2007, at 24:47 AM, Nagesh S wrote: > >> 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. >> >> ********************************************************************* >> ********************************************************************* >> ********************************************************************* >> ****************************** >> >> 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! >> >> >> >> > >
Received on Thursday, 8 February 2007 15:14:30 UTC