Re: Consolidated comments on CCXML (WD 29 June 2005) from OptimSys

Petr,

Thank you for sending these comments out. The working group will  
review these on an upcoming teleconference and report back the  
results of the review.

Thanks again,

     RJ

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



On Jul 26, 2005, at 6:28 AM, Petr Kuba wrote:

>
> Dear Voice Browser Working Group,
>
> below please find consolidated comments on the third last call CCXML
> working draft (29 June 2005) from OptimSys Ltd, Czech Republic.
> The comments are ordered by section
> and numbered for easy reference.
>
> We are glad to say that the third last call CCXML working draft has  
> clarified many issues. We appreciate your hard work.
>
> We are looking forward to your responses.
>
> Best regards,
>
>    Petr Kuba, Senior software architect
>    OptimSys Ltd.
>    kuba@optimsys.cz
>    http://www.optimsys.cz
>
>
> ===================================================================
>
> First, we would like to repeat a couple of our comments on the  
> previous working draft that have been neither reflected in the last  
> version nor (explicitly) rejected.
>
> ---
> PROBLEM 1 (previous PROBLEM 3): Different values indicating missing
> parent session
> Location: Sections 6.3.5 and 8.3
>
> Rationale:
> The description of the the 'parent' field of the 'ccxml.loaded' event
> in the Section 6.3.5 says: "The identifier of the session which issued
> the <createccxml> to start this document; if this document was started
> directly by the CCXML platform, the identifier is 0".
>
> While the description of the standard session variable
> 'session.parentid' in the Section 8.3 says: "String that indicates the
> session identifier of the parent of the CCXML session that created
> this session. In the case the current session has no parent, the value
> of the variable will be ECMAScript undefined."
>
> Both values refer to the same thing and thus should be the same.
> Moreover, the value undefined seems to be more logical than the value
> zero to indicate no parent
>
> Proposed change: Change the zero in the section 6.3.5 to undefined
>
> ---
> PROBLEM 2 (previous PROBLEM 28): Unclear attribute value
> Location: 6.2.7.2
>
> Rationale:
> In the Attribute Details table of the <fetch> tag, the following valid
> values are shown for the 'type' attribute: 'application/ccxml+xml',
> 'text/ecmascript', and 'text/javascript'. We do not understand when
> the 'text/javascript' value could appear and what it should be used
> for. Is the interpretation of this value equal to he 'text/ecmascript'
> value?
>
> Please, clarify this.
>
> ---
> PROBLEM 3 (previous PROBLEM 32): Use <dialogterminate> tag instead of
> 'connection.disconnect.hangup' event
> Location: Appendix D
>
> Rationale:
> The Second Last Working Draft of CCXML uses <dialogterminate> tag
> instead of sending 'connection.disconnect.hangup' event directly in
> the VoiceXML <disconnect> description. However, in the VoiceXML
> <transfer> description, a 'connection.disconnect.hangup' event is used
> directly. We believe that a <dialogterminate> should be used in this
> case as well.
>
> Proposed change:
> Use the <dialogterminate> tag in the VoiceXML <transfer> example
> instead of sending 'connection.disconnect.hangup' event directly.
>
> ====================================================================== 
> =
>
> Now, our new comments follow.
>
> ---
> PROBLEM 4: <log> attribute description
> Location: 6.2.11.2
>
> Rationale:
> In the description of the label attribute it is stated:
> "An ECMAScript expression which returns a character string which must
> be used, for example, to indicate the purpose of the log."
>
> In the previous version of the specification it was: "... which MAY be
> used, ..." which makes better sense.
>
> Proposed change:
> must -> may
>
> ---
> PROBLEM 5: missing attribute constrains in <dialogstart>
> Location: 7.2.2.2
>
> Rationale:
> In the previous version of the specification the following constraint
> was present for the attributes maxage, maxstale, enctype, and method:
> "This attribute may not be specified in conjunction with the
> prepareddialogid attribute."
> In the new version of the specification this constrain was removed
> from the table. We believe that the constrain makes sense and it
> should be stated.
>
> Proposed change:
> Please give the constrains back or explain why it was removed.
>
> ---
> PROBLEM 6: Delayed events
> Location: Sections 9.1, 9.2.3.2 and 9.2.5.1
>
> Rationale: There are indications of how delayed events should be
> implemented in the spec. The descriptions in 9.1 and 9.2.* collide.
> According to the 9.1 the delayed events are maintained in the target
> session while according to the 9.2.3.2 and 9.2.5.1 they are stored
> locally.
>
> Original in Section 9.1:
> When a delay is specified the event is delivered to the target CCXML
> session but it is not placed on to the event queue until the delay
> time has elapsed.
>
> Original in Section 9.2.3.2, the 'delay' attribute:
> The send tag will return immediately, but the event is not dispatched
> until the delay interval elapses.
> Note: The queue for sending events must be maintained locally. Any
> events waiting to be sent must be purged when the session that issued
> this request terminates.
>
> Original in Section 9.2.5.1:
> The cancel operation will cancel a pending event by removing it from
> the event queue of the CCXML session from which it has been sent.
>
> Proposed change in Section 9.1:
> When a delay is specified the event is not placed on to the event
> queue in the target CCXML session until the delay time has elapsed.
>
> ---
> Problem 7: optional/required marks
> Location: 10.2.3
>
> Rationale:
> In the second paragraph it is stated: "Fields marked OPTIONAL only
> appear on the event object if they have a value."
> However, the name of the table column has been changed to "Required"
> and thus the sentence should be changed analogously.
>
> Proposed change:
> "Fields not marked required only appear on the event object if they
> have a value."
>
> ---
> Problem 8: wrong media stream direction
> Location: 10.4
>
> Rationale:
> In 10.4 at the beginning of a paragraph, the following sentence is  
> stated:
> "Bridges can be either one-way, in which the media stream flows only
> from party A to party B (such that A can hear B, but B cannot hear A),
>  ..."
> The media stream direction described in the brackets is wrong, i.e. it
> does not correspond to the situation described before the bracket.
>
> Original:
> (such that A can hear B, but B cannot hear A)
>
> Proposed change:
> (such that B can hear A, but A cannot hear B)
>
> ---
> Problem 9: obsolete text
> Location: 10.4
>
> Rationale:
> In 10.4 at the end of a paragraph, the following sentence is stated:
> "This example highlights an important and subtle aspect of the
> behavior of <join> when one, or both, of the Connections being joined
> is already in one or more established bridges:"
> In the previous version of the specification this sentence was
> followed by a text that is now moved to the items above. The sentence
> does not make sense any more.
>
> Proposed change:
> remove the sentence
>
> ---
> Problem 10: illogical name of the joindirection attribute value
> Location: 10.5.4.2, description of the joindirection attribute
>
> Rationale:
> In the attribute details table of the <createcall> tag, column 'Valid'
> for the joindirection attribute shows: 'both, calltransmit,  
> callreceive'.
> However, column 'Description' describes value 'dialogreceive'. This
> seems to be a cut'n'paste problem.
>
> Original:
> dialogreceive
>
> Proposed change:
> callreceive
>
> ---
> Problem 11: connection.merged attribute name
> Location: 10.6.7
>
> Rationale:
> In the previous version of the specification the attribute name was
> 'mergedid', in the current version it is 'mergeid'.
>
> Please, could you confirm that it is not a typo?
>
> ---
> Problem 12: missing attribute 'connection' in the 'connection.signal'
> Location: 10.6.10
>
> Rationale: 'connection.signal' is the only connection.* event without
> attribute 'connection'. Since the previous version contained this
> attribute and we do not see any reason for omitting it we believe that
> this is a cut'n'paste problem.
>
> Proposed change:
> add attribute 'connection' to the 'connection.signal' event
>
> ---
> PROBLEM 13: Several typos
> We have found several typos. We list them all together here.
>
> Location: 6.2.4.1
> mustbe -> must be
>
> Location: 9.2.4.2, event attribute description
> mut->must
>
> Location: 10.5.8.1
> conferene.unjoined -> conference.unjoined
>
> Location: 11.1, error.vxml
> unavailble -> unavailable
>
>
>
>

Received on Saturday, 30 July 2005 21:34:48 UTC