Re: [cc] Questions on CCXML Working Draft 2 dated 11 October 2002

Chris,

Sorry for the delays in getting back to you on this. My reply is inline 
below:

On Wednesday, Jan 8, 2003, at 14:46 US/Pacific, Chris Parrinello wrote:

> I posted these questions on the www-voice@w3.org list but didn't 
> receive
> any responses there so I am reposting them here updated with some new
> insights.
>
> Section 9.2.4
>
> The description of the <move> tag is a little confusing to me. I think
> my confusion stems from the use of the term "endpoint" to define where
> an event originates. I would recommend perhaps changing the terms to
> "sink"/"source" or "origination/destination" to make the description a
> little easier to understand. When I read "endpoint", I think of where
> the event is being sent TO rather than where it is being sent FROM.

We can try to clarify the terminology used in the spec if it seems to 
be unclear. Just to give you some background info on what the <move> 
tag was created for, it was for moving the processing of an event or 
source from one document to another allowing you to for example spin 
off processing for individual call legs into different documents if you 
wished.

> Now that I have a little better understanding of the <move> tag, the
> details of the attributes are troublesome. What happens if a <move> tag
> uses both the endpoint and event attributes but the event has a
> different endpoint than specified in the endpoint attribute? Is this
> still a valid <move> tag? Should both endpoints be moved if it is 
> allowable?

This is a good point and should be clarified in the document. We will 
assign a clarification request to this issue.

> Section 10.3
>
> For the conferencing set of tags, the spec says that an asynchronous
> event will be posted to the document when a conference operation is
> completed but, except in the case of a <join>, the spec doesn't say 
> what
> event types are sent. I would think that you would want an event when a
> <createconference> tag succeeds or fails so that you can follow that
> event up with <join>s or error handling.
>
> Otherwise, you might get into a race condition where the a <transition>
> block has a <createconference> tag followed directly by <join>s for 
> that
> conference. If the platform hasn't finished setting up the conference,
> the <join> could fail. This is assuming that <createconference> is
> supposed to be an asynchronous operation. Please correct me if my
> assumption is incorrect.

You are correct and we are are indeed in the process of cleaning up the 
telephony events and conferencing error/success events are at the top 
of the list of things that are being addressed.

I hope this answers your questions. If there are any more questions 
please don't hesitate to let me know,

	RJ

---
RJ Auburn
CTO, Voxeo Corporation
Chair, Call Control Subgroup, VBWG, W3C.

Received on Sunday, 12 January 2003 19:14:49 UTC