Re: CCXML: comment on ISSUE-729

Chris and Petr:

The issue here is that for dialog.user.* events there is no standard way in VoiceXML to generate the events without using the BasicHTTP/IO processor. Our thought that is if the application is raising the event via basic HTTP (as the test currently does) it will depend on the semantics, limitations etc of the basic HTTP IO processor. If it's coming in via some other platform specific dialog interface it would then depend on what that interface imposes. In the case below you will be hitting the rules around eventsource/type that appendix K outlines (as highlighted by Chris below) where eventsource is optional and eventsourcetype will be populated as basichttp. 

As such we don't think there are any changes requires to the test or the specification at this point. Please let us know if you have any concerns or comments on this resolution and we can reopen the issue. 

Best regards,

	RJ

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



On Aug 3, 2010, at 12:17 PM, Chris Davis wrote:

> Petr,
> 
> Admittedly, there are a number of square pegs that don't fit into round holes here. What I mean by that is
> the following:
> 
> 1) CCXML has a defined interface to receive unsolicited asynchronous HTTP events; VoiceXML2.0/2.1 does not.
> 2) CCXML's standard event attribute table(9.4.2.2) lists attributes that should be
> present on CCXML events; but often they don't apply (Example: eventid from a basichttp? what is that supposed to be?)
> 3) CCXML section K says eventsource is optional; 9.4.2.2 says it is required
> 
> In your example where <send> is used within CCXML to talk to another CCXML
> the eventsource would be set by the sender because it makes sense -  the sender can be
> reached at a URI (which is the value of session.ioprocessors["basichttp"]). That URI is
> its well defined basichttp interface listed in section K. I don't see how this example
> is related to what we are discussing because VoiceXML has no such equivalent defined
> HTTP interface(#1 above), and eventsource is optional when received via basichttp (#3 above).
> 
> >>Regarding the issue I reported, could you explain me how you guess the value of the eventsource in your Event I/O Processor?
> 
> It doesn't. Section K says eventsource is optional (See #3 above). My comment yesterday was for the
> required attributes through section K, not of 9.4.2.2. Sorry about that confusion.
> 
> >>And are you able to use this value to send an event from CCXML to VoiceXML using basichttp?
> 
> No. VoiceXML has no defined HTTP interface to receive unsolicited events. We "send events" to
> VoiceXML through a custom interface (not HTTP) only for things like <dialogstart> and <dialogterminate>
> and as part of VXML <transfer>.
> In those cases we map back to the IPC mechanism via the dialogid.
> 
> I suggested that we reject your issue because you are suggesting a resolution that requires VoiceXML
> (the app, not the internals) to require a minimum of *FIVE* arguments on the namelist instead of 2
> when communicating to CCXML (name, sessionid,eventid,eventsource, and eventsourcetype).
> The preferred alternative is just name and sessionid for any <data> usage.
> 
> Of those extra 3 args, eventsource and eventsourcetype have no meaning coming from VoiceXML.
> eventid also has no explained value as CCXML only wants it to match the <send> but it didn't even
> come from <send> in this case.
> 
> If something can be done with 2 arguments instead of 5, is it a better interface?
> 
> Regards,
> Chris
> 
> Petr Kuba wrote:
>> Hello Chris,
>> 
>> My understanding of "It is the responsibility ... to make sure that they are present." is that the Event I/O Processor should REJECT any events that do not contain required attributes not that it should create them.
>> 
>> Especially in case of eventsource the Event I/O Processor can hardly know what value should be used. The eventsource value specifies a URI to which events may be sent. It means that the sender must fill it in to inform the receiver how to answer.
>> 
>> Imagine a situation where one CCXML interpreter sends an event to another one using basichttp. The Event I/O Processor of the target CCXML interpreter cannot create eventsource attribute because it doesn't know id of the session that sent the event, the URI of the sending CCXML platform and it doesn't even know that he is receiving event from another CCXML platform. So the format and structure of the eventsource is completely unknown for the receiving Event I/O Processor.
>> 
>> You are correct that VoiceXML is not an I/O processor. In the issue I reported it must be responsibility of the VoiceXML script to insert eventsource value into the <data> tag. VoiceXML implementation doesn't have to know anything about the CCXML internals. Only the application programmer has to know it (and it is OK).
>> 
>> Regarding the issue I reported, could you explain me how you guess the value of the eventsource in your Event I/O Processor? And are you able to use this value to send an event from CCXML to VoiceXML using basichttp?
>> 
>> I believe that you are wrong in your understanding and there is no point to reject the issue.
>> 
>> Regards,
>> Petr
>> 
>> On 2.8.2010 18:41, Chris Davis wrote:
>>> Hello www-voice,
>>> 
>>> The question:
>>> -------
>>> "Who is responsible for inserting the required attributes in this case
>>> where the event is sent from a VoiceXML application using basichttp? I
>>> assume that it is responsibility of the VoiceXML application."
>>> ----------
>>> I think the answer is "the basic http processor is responsible", because
>>> 9.4.2.1 says:
>>> "It is the responsibility of the Event I/O
>>> Processor that delivered the event to make sure that they are present."
>>> 
>>> VoiceXML is *not* an I/O processor. By definition, the <data> work
>>> is flowing through the basichttp processor that translates HTTP into CCXML
>>> events.
>>> 
>>> My understanding of the section of 9.1 that Petr quoted refers to users of
>>> CCXML <send> who do not format their events correctly and so it doesn't
>>> apply here.
>>> 
>>> We recommend this issue be rejected for the above reasons. A positive side
>>> effect is that VoiceXML also needs to know less of the internals of CCXML
>>> (eventid, eventsource, and eventsourcetype).
>>> 
>>> Regards,
>>> Chris
>>> 
>>> 
>>> On Jul 26, 2010, at 3:15 AM, Petr Kuba wrote:
>>> 
>>>> Hello www-voice,
>>>> 
>>>> In 7_2, the 'dialog.user.test' event is rejected because it doesn't
>>>> contain required attributes eventid, eventsource, and eventsourcetype
>>>> (according to the CCXML specification, sections 9.4.2).
>>>> 
>>>> Section 9.1 states:
>>>> 
>>>> "Platforms SHOULD reject any standard events that do not contain all
>>>> of the mandatory properties defined in this specification, and SHOULD
>>>> notify the sender of the rejection (for instance with an error.send
>>>> event)."
>>>> 
>>>> Who is responsible for inserting the required attributes in this case
>>>> where the event is sent from a VoiceXML application using basichttp? I
>>>> assume that it is responsibility of the VoiceXML application.
>>>> 
>>>> Please clarify and fix the test.
>>>> 
>>>> Thanks,
>>>> Petr
>>> 
>> 
>> 
> 
> 
> -- 
> Chris Davis
> Interact Incorporated R&D
> 512-502-9969x117
> 
> 
>

Received on Thursday, 16 September 2010 12:30:56 UTC