Subject: [MEDIACTRL] RAI-Art review of draft-ietf-mediactrl-ivr-control-package-00

From: Ben Campbell <[email-masked]>
Date: Thu, 24 Jul 2008 21:07:08 -0500

[Oops, sent from wrong account. Sorry for the repeat. ]

I am the assigned RAI-ART reviewer for draft-ietf-mediactrl-ivr- 
control-package-00

For background on RAI-ART, please see the FAQ at <http://www.softarmor.com/rai/art/rai-art-FAQ.html 
 >.

Please resolve these comments along with any other comments you may  
receive.

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)

Thanks!

Ben.

_______________________________________________
MEDIACTRL mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mediactrl
Supplemental Web Site:
http://www.standardstrack.com/ietf/mediactrl

---

From: "McGlashan, Scott" <[email-masked]>
Date: Sat, 26 Jul 2008 15:06:27 +0000

Ben,

Thanks for these comments. We'll review them in the MediaCtrl WG meeting on Wednesday and then get back to you.

Scott

-----Original Message-----
From: Ben Campbell [mailto:[email-masked]]
Sent: Friday, July 25, 2008 04:07
To: [email-masked]; [email-masked]
Cc: McGlashan, Scott; Tim Melanchuk; Chris Boulton; Spencer Dawkins; Eric Burger; Jon Peterson; Cullen Jennings
Subject: RAI-Art review of draft-ietf-mediactrl-ivr-control-package-00

I am the assigned RAI-ART reviewer for draft-ietf-mediactrl-ivr- control-package-00

Please resolve these comments along with any other comments you may receive.

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>

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.

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.

--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:

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.)

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:

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?

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

"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

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)

Thanks!

Ben.