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

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 Tuesday, 26 July 2005 10:28:49 UTC