Document: draft-ietf-mediactrl-ivr-control-package-00
Reviewer: Ben Campbell [ben@estacado.net]
Review Date: 7/24/2008
Review Deadline: 7/25/2008
Review Type: Initial Review

Summary:

I think the document is on the right track. I have a few questions, one possibly substantive comment, and several mainly editorial comments



<disclaimer>This draft depends heavily on the mediactrl-framework, which I previously reviewed. Please don't take any statements in _this_ review to indicate any particular opinion on the framework--I did this review under the assumption that any issues in the framework are not the problem of _this_ draft. </disclaimer>

Substantive question/comment:

The security considerations section is very light. Do you really believe there are no security considerations here beyond those of RFC3023? I'm not saying that I know of any specific issues, but an almost empty security considerations section raises a red flag in my head.

General comments and questions:

I fear that use of the term "dialog" through out this document is going to collide heavily with the SIP usage of the same term in peoples heads. I imagine frustrating conversations along the lines of "Wait, did you mean the IVR dialog, or the SIP dialog?" OTOH, I assume that "dialog" is a common term in the IVR industry. It might help a little to have a very early disclaimer that "dialogs" in this document are completely unrelated to SIP dialogs.

How does this package relate to KPML? I notice that you could supply a KPML grammar, but it seems like some of the functionality here might overlap with that of KPML. Is this something the work group thought about?

I notice the phrase "It is an error if..." throughout this document.  
That makes me wonder if there are not implicit normative assumptions in at least some of these that should be stated explicitly with 2119 language. At least, in cases where the "It is an error..." phrase relates back to some "If an error occurs..." assertion, some more info about what error codes are appropriate might help.

I'd like to see a (potentially non-normative) paragraph or two explaining in general how dialogids work. It looks like the MS is generally responsible for this, but the AS can attempt to assign them itself. Bits of this are spread out through the various element definitions--it would be nice to consolidate them.


Specific Section Comments:

--Introduction

You make ASR explicitly out of scope. Is there an effort for extending this to support ASR? I note that fully half of the IVR applications I interact with these days support some degree of ASR.

--4.2, last paragraph:

"It is an error to prepare or start a dialog with the same dialogid as
   that of a dialog on the MS which is in the state PREPARING,..."

In the previous description of the states, there was no mention of a dialog in the PREPARING state having a dialogid. (it is explicitly mentioned for the PREPARED state.)

--4.2.1, "src" attribute:

What URI schemes make sense here? It probably doesn't need a list of specific schemes, but some general guidance would help. For example, I assume "mailto" probably does not make sense. Is there an error code for "unknown URI scheme"?

--4.2.1, last paragraph:

"Since MS support for dialog types other than the IVR dialog type is
   optional, if the MS does not support the dialog type, it MUST send a
   response with the status code 409 (dialog type not supported)."


What, in the protocol, defines dialog type? Is the <dialog> element assumed to be the IVR dialog type, and some other dialog type would use a different element name? Or is it the <mscivr> root element? It is also confusing here that there is a "type" attribute that takes a MIME media type. Does this paragraph indicate that if an unknown media type is indicated in the "type" attribute that the MS would send a 409?

--4.2.5.2, dtmf and timestamp attributes:

Am I correct in assuming that dtmf can hold a string of digits? If so, what does the timestamp indicate? First digit? Last digit?

--4.2.6.1, "type" attribute

"type" is optional and has no default--how should the value be interpreted if "type" is not present? How do "type" and "valuetype"  
interact?

--4.3.1:

"The behavior is not
   defined if both <collect> and <record> are specified. "

Does that imply a 2119 normative statement?

-4.3.1, numbered list of IVR execution model

The passive voice language in the previous section obscures which device is responsible for doing these things. (A counter is initialized, a duration timer is started, etc.) The MS, I assume?

-- 6.2.2:

Example is entitled "Prompt and collect", but description says "This example plays no prompts..."

Section 12:

Is 2119 really the only normative reference? I would think at least the mediactrl framework draft would be a normative reference. You had a MUST level reference to RFC 3023 in section 7. The "label" attribute in 4.2.2.2 refers to RFC4574. (These are possible examples, not an exhaustive list)