An Interactive Voice Response (IVR) Control Package for the Media Control Channel Framework
draft-ietf-mediactrl-ivr-control-package-11

Upon approval of this document, IANA understands that there are four
actions that IANA must complete. One of the actions required is
dependent upon a registry created in another document.

First, in the new Media Control Channel Framework registry created by
publication of the document ietf-mediactrl-sip-control-framework, a new
registration is to be added as follows:

Package Name: msc-ivr/1.0
Published Specification(s): [RFC-to-be]
Person & email address to contact for further information: IETF, MEDIACTRL
working group, (mediactrl@ietf.org), Scott McGlashan
(smcg.stds01@mcglashan.org).

Second, in the XML namespace registry located at:

http://www.iana.org/assignments/xml-registry/ns.html

a new registration is to be made as follows:

ID: msc-ivr
URI: urn:ietf:params:xml:ns:msc-ivr
Registraion templace: [as in RFC-to-be Section 8.2]
Reference: [RFC-to-be]

Third, in the XML schema registration located at:

http://www.iana.org/assignments/xml-registry/ns.html

a new registration is to be made as follows:

ID: urn:ietf:params:xml:ns:msc-ivr
URI: msc-ive
Registration template: [as in RFC-to-be Section 8.3]
Reference: [RFC-to-be]

Four, in the Application Media Types registry for MIME media types
located at:

http://www.iana.org/assignments/media-types/application/

a new registration is to be made as follows:

application/msc-ivr+xml
[RFC-to-be]

IANA understands that these are the only actions that need to be
completed upon approval of this document.

State changed to In Last Call from Last Call Requested.

The following Last Call Announcement was sent out:

From: The IESG
To: IETF-Announce
CC:
Reply-To: ietf@ietf.org
Subject: Additional Last Call:  (An Interactive Voice Response (IVR) Control Package for the Media Control Channel Framework) to Proposed Standard

The IESG has received a request from the Media Server Control WG
(mediactrl) to consider the following document:
- 'An Interactive Voice Response (IVR) Control Package for the Media
  Control Channel Framework'
  as a Proposed
Standard

Last calls were earlier issued on versions -08 and -09 of this document.

As part of resolving comments from earlier IETF last calls and IESG review, the reference
to RFC4627 ("The application/json Media Type for JavaScript Object Notation (JSON)")
was made Normative introducing a downref (see BCP 97).

This last call requests comments on whether this downward reference is appropriate
in a standards track publication.

The IESG plans to make a decision in the next few weeks, and solicits
final comments on this action. Please send substantive comments to the
ietf@ietf.org mailing lists by 2011-01-25. Exceptionally, comments may be
sent to iesg@ietf.org instead. In either case, please retain the
beginning of the Subject line to allow automated sorting.

The file can be obtained via
http://datatracker.ietf.org/doc/draft-ietf-mediactrl-ivr-control-package/

IESG discussion can be tracked via
http://datatracker.ietf.org/doc/draft-ietf-mediactrl-ivr-control-package/

[Ballot discuss]
I think the document is in a pretty good shape despite the length of my comments.

Below are some blocking comments that need to be discussed and possibly addressed before I can recommend approval of this document:

2) Use of authentication information in URIs in the "src" attribute (in multiple sectons):

E.g. in Section 4.2.1:

  src:  specifies the location of an external dialog document to
      prepare.  A valid value is a URI (see Section 4.6.9) including
      authentication information if defined by the URI scheme (e.g.
      basic access authentication in HTTP).

Is this supposed to include the password as well?
If yes, how can this be represented in URIs?
If not, where is this information coming from?

8) In 4.6.10:

  A string formated as a IANA MIME media type ([MIME.mediatypes]).

The latest version is an improvement, but I think you are missing parameter values in the ABNF ("=" value),
where "value" is defined in RFC 2045.

9) In 4.3.1.4:

  append:  indicates whether recorded data is appended or not to a
      recording location if a resource already exists.  A valid value is
      a boolean (see Section 4.6.1).  A value of true indicates that
      recorded data is appended to the existing resource at a recording
      location.  A value of false indicates that recorded data is to
      overwrite the existing resource.  The attribute is optional.  The
      default value is false.

How is append/overwrite mapped to underlying protocol being used?
In particular, I think this is underspecified in case of HTTP.

10) In 9 (previously Appendix A/Section 12):

This section and its subsections are normative for somebody who chooses
to implement VoiceXML as a dialog language. This in its turn means that
the following references:

  [RFC4627]  Crockford, D., "The application/json Media Type for
              JavaScript Object Notation (JSON)", RFC 4627, July 2006.

  [VXML30]  McGlashan, S., Auburn, RJ., Baggia, P., Barnett, J.,
              Bodell, M., Burnett, D., Carter, J., Oshry, M., Rehor, K.,
              Young, M., and R. Hosn, "Voice Extensible Markup Language
              (VoiceXML) Version 3.0", W3C Working Draft, December 2008.

are Normative (they are currently Informative).

11) BCP 18 (RFC 2277) requires that any human readable text is explicitly or implicitly tagged with a language tag. This affects the following fields in your document:

4.2.4. 

  reason:  string specifying a reason for the response status.  The
      attribute is optional.  There is no default value.

4.2.5.1. 

  reason:  a textual description which the MS SHOULD use to provide a
      reason for the status code; e.g. details about an error.  A valid
      value is a string (see Section 4.6.6).  The attribute is optional.
      There is no default value.

4.4.2. 

  reason:  string specifying a reason for the status.  The attribute is
      optional.

4.4.2.2.5.1. 

  desc:  a string providing some textual description of the type and
      format.  The attribute is optional.

Language tagging is missing here

  :  element with a desc attribute (optional description)

As above

      and a content model describing a supported format in the
      format attribute.  The element is optional.


While adding the xml:lang attribute to various identified places (and update the XML Schema accordingly) would be the easiest way to address that, it might not work for you as xml:lang is already used for another purpose. Other alternatives might be more suitable for you.
(See  for a bit more details)

Also note that some of the examples might have to be updated to show language tagging.

[Ballot discuss]
I think the document is in a pretty good shape despite the length of my comments.

Below are some blocking comments that need to be discussed and possibly addressed before I can recommend approval of this document:

2) Use of authentication information in URIs in the "src" attribute (in multiple sectons):

E.g. in Section 4.2.1:

  src:  specifies the location of an external dialog document to
      prepare.  A valid value is a URI (see Section 4.6.9) including
      authentication information if defined by the URI scheme (e.g.
      basic access authentication in HTTP).

Is this supposed to include the password as well?
If yes, how can this be represented in URIs?
If not, where is this information coming from?

8) In 4.6.10:

  A string formated as a IANA MIME media type ([MIME.mediatypes]).

The latest version is an improvement, but I think you are missing parameter values in the ABNF ("=" value),
where "value" is defined in RFC 2045.

9) In 4.3.1.4:

  append:  indicates whether recorded data is appended or not to a
      recording location if a resource already exists.  A valid value is
      a boolean (see Section 4.6.1).  A value of true indicates that
      recorded data is appended to the existing resource at a recording
      location.  A value of false indicates that recorded data is to
      overwrite the existing resource.  The attribute is optional.  The
      default value is false.

How is append/overwrite mapped to underlying protocol being used?
In particular, I think this is underspecified in case of HTTP.

10) In 9 (previously Appendix A/Section 12):

This section and its subsections are normative for somebody who chooses
to implement VoiceXML as a dialog language. This in its turn means that
the following references:

  [RFC4627]  Crockford, D., "The application/json Media Type for
              JavaScript Object Notation (JSON)", RFC 4627, July 2006.

  [VXML30]  McGlashan, S., Auburn, RJ., Baggia, P., Barnett, J.,
              Bodell, M., Burnett, D., Carter, J., Oshry, M., Rehor, K.,
              Young, M., and R. Hosn, "Voice Extensible Markup Language
              (VoiceXML) Version 3.0", W3C Working Draft, December 2008.

are Normative (they are currently Informative).

11) BCP 18 (RFC 2277) requires that any human readable text is explicitly or implicitly tagged with a language tag. This affects the following fields in your document:

4.2.4. 

  reason:  string specifying a reason for the response status.  The
      attribute is optional.  There is no default value.

4.2.5.1. 

  reason:  a textual description which the MS SHOULD use to provide a
      reason for the status code; e.g. details about an error.  A valid
      value is a string (see Section 4.6.6).  The attribute is optional.
      There is no default value.

4.4.2. 

  reason:  string specifying a reason for the status.  The attribute is
      optional.

4.4.2.2.5.1. 

  desc:  a string providing some textual description of the type and
      format.  The attribute is optional.

Language tagging is missing here

  :  element with a desc attribute (optional description)

As above

      and a content model describing a supported format in the
      format attribute.  The element is optional.


I think the easiest way to address this would be to add xml:lang attribute to various identified places (and update the XML Schema accordingly), however other alternatives might be more suitable for you.
(See  for a bit more details)

Also note that some of the examples might have to be updated to show language tagging.

[Ballot comment]
4.6.4.  Non-Negative Integer

  The value space of non-negative integer is the infinite set
  {0,1,2,...}.

(And the same comment for positive integers)
Is making this unbounded truly necessary? This might be a burden on
implementations and many (most?) will limit it anyway.

[Ballot discuss]
I think the document is in a pretty good shape despite the length of my comments.

Below are some blocking comments that need to be discussed and possibly addressed before I can recommend approval of this document:

2) Use of authentication information in URIs in the "src" attribute (in multiple sectons):

E.g. in Section 4.2.1:

  src:  specifies the location of an external dialog document to
      prepare.  A valid value is a URI (see Section 4.6.9) including
      authentication information if defined by the URI scheme (e.g.
      basic access authentication in HTTP).

Is this supposed to include the password as well?
If yes, how can this be represented in URIs?
If not, where is this information coming from?

6) In Section 12.4:

  |  | name="__reason">exit true      |

This doesn't seem to match your definition of how "expr" is converted to

<>

8) In 4.6.10:

  A string formated as a IANA MIME media type ([MIME.mediatypes]).

The latest version is an improvement, but I think you are missing parameter values in the ABNF ("=" value),
where "value" is defined in RFC 2045.

9) In 4.3.1.4:

  append:  indicates whether recorded data is appended or not to a
      recording location if a resource already exists.  A valid value is
      a boolean (see Section 4.6.1).  A value of true indicates that
      recorded data is appended to the existing resource at a recording
      location.  A value of false indicates that recorded data is to
      overwrite the existing resource.  The attribute is optional.  The
      default value is false.

How is append/overwrite mapped to underlying protocol being used?
In particular, I think this is underspecified in case of HTTP.

10) In 12:

This section and its subsections are using RFC 2119 language, so they
look normative for somebody who chooses to implement VoiceXML as a dialog
language. This in its turn means that some of the following references:

  [RFC4627]  Crockford, D., "The application/json Media Type for
              JavaScript Object Notation (JSON)", RFC 4627, July 2006.


  [VXML30]  McGlashan, S., Auburn, RJ., Baggia, P., Barnett, J.,
              Bodell, M., Burnett, D., Carter, J., Oshry, M., Rehor, K.,
              Young, M., and R. Hosn, "Voice Extensible Markup Language
              (VoiceXML) Version 3.0", W3C Working Draft, December 2008.

are Normative (they are currently Informative).

11) BCP 18 (RFC 2277) requires that any human readable text is explicitly or implicitly tagged with a language tag. This affects the following fields in your document:

4.2.4. 

  reason:  string specifying a reason for the response status.  The
      attribute is optional.  There is no default value.

4.2.5.1. 

  reason:  a textual description which the MS SHOULD use to provide a
      reason for the status code; e.g. details about an error.  A valid
      value is a string (see Section 4.6.6).  The attribute is optional.
      There is no default value.

4.4.2. 

  reason:  string specifying a reason for the status.  The attribute is
      optional.

4.4.2.2.5.1. 

  desc:  a string providing some textual description of the type and
      format.  The attribute is optional.

Language tagging is missing here

  :  element with a desc attribute (optional description)

As above

      and a content model describing a supported format in the
      format attribute.  The element is optional.


I think the easiest way to address this would be to add xml:lang attribute to various identified places (and update the XML Schema accordingly), however other alternatives might be more suitable for you.
(See  for a bit more details)

Also note that some of the examples might have to be updated to show language tagging.

[Ballot discuss]
The document mentions the need for a standards-track RFC. It would be
better to define such policy by referring to the terms defined in RFC
5226. In this case, standards action.

[Ballot comment]
At the beginning of the Introduction, There are two capitalized terms
in the text: "Media Control Channel Framework" and "Control
Framework". Stating whether the terms are equivalent would be useful.

Make sure all acronyms are expanded on their first use (e.g., DTMF).

[Ballot discuss]
The document mentions the need for a standards-track RFC. It would be
better to define such policy by referring to the terms defined in RFC
5226. In this case, standards action.

[Ballot comment]
1. The following sentence does not parse:

  If no  child element is specified, the MS MUST provide a
  recording location where the recording format is implementation-
  specific.

[Ballot discuss]
1. Please clarify how implementations will achieve interoperability with regard to the  element, given that there are no registries or specifications for the 'type' and 'format' attributes. This applies also to the  element.

2. The  element defines no restrictions on its  children, with the result that a dialog could be defined to simultaneously play multiple audio streams or multiple video streams. However, the specification does not define how to handle multiple streams of the same media type. It would be better to at least recommend that a  element contain only one  element of the same media type (not including sub-type). If this is perhaps defined in W3C.REC-SMIL2-20051213, please note that.

3. I concur with Alexey Melnikov's DISCUSS regarding inclusion of credentials in the 'src' attribute for , , and  and the 'loc' attribute for the  element.

4. Please see my comments on draft-ietf-mediactrl-mixer-control-package, since many of them also apply to draft-ietf-mediactrl-ivr-control-package. As one example, see my comments regarding the mixed content model for the  element.

[Ballot comment]
4.2.2.2.1. 

  The  element is used to specify the region within a video
  layout where a video media stream is displayed.

What is a "region"? Is this the same as the DVD region?


4.3.1.1.1. 

  A  element has the following attributes:

  value:  specifies the string to be rendered.  A valid value is a
      string (see Section 4.6.6).  The attribute is mandatory.

  type:  specifies the type to use for rendering.  A valid value is a
      string (see Section 4.6.6).  The attribute is mandatory.

  format:  specifies format information to use in conjunction with the
      type for the rendering.  A valid value is a string (see
      Section 4.6.6).  The attribute is optional.  There is no default
      value.

Are these defined somewhere in more details?

  For example, the MS could support  type/format combinations
  such as:

Is this the complete list?

4.6.4.  Non-Negative Integer

  The value space of non-negative integer is the infinite set
  {0,1,2,...}.

(And the same comment for positive integers)
Is making this unbounded truly necessary? This might be a burden on
implementations and many (most?) will limit it anyway.

4.6.11.  Language Identifier

  A language identifier labels information content as being of a
  particular human language variant.  Following the XML specification
  for language identification [XML], a legal language identifier is
  identified by a RFC566 ([RFC5646]) and RFC4647 ([RFC4647]) code where

typo: RFC5646

  the language code is required and a country code or other subtag
  identifier is optional.

[Ballot discuss]
I think the document is in a pretty good shape despite the length of my comments.

Below are some blocking comments that need to be discussed and possibly addressed before I can recommend approval of this document:

1) In Section 4:

  The MS MUST
  support one or more schemes using communication protocols suitable
  for fetching resources (e.g.  HTTP).

I don't think this is good enough for interoperability. You should specify a mandatory to implement protocol for fetching resources.
I suggest you mandate use of HTTP and HTTPS. (The latter is important for providing data confidentiality)

The same issue is relevant in section 4.3.1.4 - a mandatory to implement protocol for recording data.

2) Use of authentication information in URIs in the "src" attribute (in multiple sectons):

E.g. in Section 4.2.1:

  src:  specifies the location of an external dialog document to
      prepare.  A valid value is a URI (see Section 4.6.9) including
      authentication information if defined by the URI scheme (e.g.
      basic access authentication in HTTP).

Is this supposed to include the password as well?
If yes, how can this be represented in URIs?
If not, where is this information coming from?

3) Multiple typos in XML examples (I haven' checked all, but spotted some problems):

4.2.2.1:

 
   
   

     
     
     
     

I think "rewkey" should be "rwkey"

   
   
   
   
   
 

4.3.1.1.3:

 
 
   

     
     
       
        ".

     
     
   
   
 


4.3.1.1.3.1:

 
 
   

     
     
       
         
         
         
         
       
        "

     
     
   
   
 

4) In 4.2.2.2:

  The  element has the following attributes:

  media:  a string indicating the type of media associated with the
      stream.  The following values MUST be used for common types of
      media: "audio" for audio media, and "video" for video media.  The
      attribute is mandatory.

Is there a registry (or at least a full list) of valid names?
Or did you mean "MIME type"?

5) In 12.2.2:

  format  This property is optional.  If defined, the value of the
      property is an array.  Each array element is an object which
      specifies information about one format of the media stream.  The
      object contains at least one property called name whose value is
      the subtype of the media format ([RFC4855]).

Here you say subtype, but your example later in the same section shows:

  In this case, session.connection.protocol.sip.media[0].type evaluates
  to "audio", session.connection.protocol.sip.media[0].direction to
  "recvonly" (i.e. the endpoint only receives media from the dialog -
  the endpoint does not send media to the dialog), and
  session.connection.protocol.sip.media[0].format[0].name evaluates to
  "audio/PCMU" and

I.e. I think this should be "PCMU", or you need to correct the definition above.

  session.connection.protocol.sip.media[0].format[0].rate evaluates to
  "8000".

6) In Section 12.4:

  |  | name="__reason">exit true      |

This doesn't seem to match your definition of how "expr" is converted to

7) In 4.2.6.1:

 
   
   
   
      recording
     

     

You have a problem here, as your data is base-64 encoded, yet you don't specify anywhere in the payload that that is being the case. And there is no text saying when this is implied for particular MIME types.

So I think this is missing information about Content-Transfer-Encoding.
It looks like Content-Transfer-Encoding (pick your attribute name) needs to be another attribute to "param".

     
   
   
   
 

8) In 4.6.10:

  A string formated as a IANA MIME media type ([MIME.mediatypes]).

Firstly, I think this should also point to exact ABNF for this.
It is also not clear if Content-type parameters are allowed in this field. Some of your uses of this type imply so, while other don't.

For MIME type/subtype ABNF, please reference Section 4.2 of RFC 4288.
I would also encourage you to specify proper ABNF for this production (and to reference "type-name" and "subtype-name" from Section 4.2 of RFC 4288)

9) In 4.3.1.4:

  append:  indicates whether recorded data is appended or not to a
      recording location if a resource already exists.  A valid value is
      a boolean (see Section 4.6.1).  A value of true indicates that
      recorded data is appended to the existing resource at a recording
      location.  A value of false indicates that recorded data is to
      overwrite the existing resource.  The attribute is optional.  The
      default value is false.

How is append/overwrite mapped to underlying protocol being used?
In particular, I think this is underspecified in case of HTTP.

10) In 12:

This section and its subsections are using RFC 2119 language, so they
look normative for somebody who chooses to implement VoiceXML as a dialog
language. This in its turn means that some of the following references:

  [RFC4627]  Crockford, D., "The application/json Media Type for
              JavaScript Object Notation (JSON)", RFC 4627, July 2006.

  [VXML20]  McGlashan, S., Burnett, D., Carter, J., Danielsen, P.,
              Ferrans, J., Hunt, A., Lucas, B., Porter, B., Rehor, K.,
              and S. Tryphonas, "Voice Extensible Markup Language
              (VoiceXML) Version 2.0", W3C Recommendation, March 2004.

  [VXML21]  Oshry, M., Auburn, RJ., Baggia, P., Bodell, M., Burke, D.,
              Burnett, D., Candell, E., Carter, J., McGlashan, S., Lee,
              A., Porter, B., and K. Rehor, "Voice Extensible Markup
              Language (VoiceXML) Version 2.1", W3C Recommendation,
              June 2007.

  [VXML30]  McGlashan, S., Auburn, RJ., Baggia, P., Barnett, J.,
              Bodell, M., Burnett, D., Carter, J., Oshry, M., Rehor, K.,
              Young, M., and R. Hosn, "Voice Extensible Markup Language
              (VoiceXML) Version 3.0", W3C Working Draft, December 2008.

are Normative (they are currently Informative).

11) BCP 18 (RFC 2277) requires that any human readable text is explicitly or implicitly tagged with a language tag. This affects the following fields in your document:

4.2.4. 

  reason:  string specifying a reason for the response status.  The
      attribute is optional.  There is no default value.

4.2.5.1. 

  reason:  a textual description which the MS SHOULD use to provide a
      reason for the status code; e.g. details about an error.  A valid
      value is a string (see Section 4.6.6).  The attribute is optional.
      There is no default value.

4.4.2. 

  reason:  string specifying a reason for the status.  The attribute is
      optional.

4.4.2.2.5.1. 

  desc:  a string providing some textual description of the type and
      format.  The attribute is optional.

Language tagging is missing here

  :  element with a desc attribute (optional description)

As above

      and a content model describing a supported format in the
      format attribute.  The element is optional.


I think the easiest way to address this would be to add xml:lang attribute to various identified places (and update the XML Schema accordingly), however other alternatives might be more suitable for you.
(See  for a bit more details)

Also note that some of the examples might have to be updated to show language tagging.

[Ballot comment]
4.2.2.2.1. 

  The  element is used to specify the region within a video
  layout where a video media stream is displayed.

What is a "region"? Is this the same as the DVD region?


4.3.1.1.1. 

  A  element has the following attributes:

  value:  specifies the string to be rendered.  A valid value is a
      string (see Section 4.6.6).  The attribute is mandatory.

  type:  specifies the type to use for rendering.  A valid value is a
      string (see Section 4.6.6).  The attribute is mandatory.

  format:  specifies format information to use in conjunction with the
      type for the rendering.  A valid value is a string (see
      Section 4.6.6).  The attribute is optional.  There is no default
      value.

Are these defined somewhere in more details?

  For example, the MS could support  type/format combinations
  such as:

Is this the complete list?

4.6.4.  Non-Negative Integer

  The value space of non-negative integer is the infinite set
  {0,1,2,...}.

(And the same comment for positive integers)
Is making this unbounded truly necessary? This might be a burden on
implementations and many (most?) will limit it anyway.

4.6.11.  Language Identifier

  A language identifier labels information content as being of a
  particular human language variant.  Following the XML specification
  for language identification [XML], a legal language identifier is
  identified by a RFC566 ([RFC5646]) and RFC4647 ([RFC4647]) code where

typo: RFC5646

  the language code is required and a country code or other subtag
  identifier is optional.

[Ballot discuss]
I think the document is in a pretty good shape despite the length of my comments.

Below are some blocking comments that need to be discussed and possibly addressed before I can recommend approval of this document:

1) In Section 4:

  The MS MUST
  support one or more schemes using communication protocols suitable
  for fetching resources (e.g.  HTTP).

I don't think this is good enough for interoperability. You should specify a mandatory to implement protocol for fetching resources.
I suggest you mandate use of HTTP and HTTPS. (The latter is important for providing data confidentiality)

The same issue is relevant in section 4.3.1.4 - a mandatory to implement protocol for recording data.

2) Use of authentication information in URIs in the "src" attribute (in multiple sectons):

E.g. in Section 4.2.1:

  src:  specifies the location of an external dialog document to
      prepare.  A valid value is a URI (see Section 4.6.9) including
      authentication information if defined by the URI scheme (e.g.
      basic access authentication in HTTP).

Is this supposed to include the password as well?
If yes, how can this be represented in URIs?
If not, where is this information coming from?

3) Multiple typos in XML examples (I haven' checked all, but spotted some problems):

4.2.2.1:

 
   
   

     
     
     
     

I think "rewkey" should be "rwkey"

   
   
   
   
   
 

4.3.1.1.3:

 
 
   

     
     
       
        ".

     
     
   
   
 


4.3.1.1.3.1:

 
 
   

     
     
       
         
         
         
         
       
        "

     
     
   
   
 

4) In 4.2.2.2:

  The  element has the following attributes:

  media:  a string indicating the type of media associated with the
      stream.  The following values MUST be used for common types of
      media: "audio" for audio media, and "video" for video media.  The
      attribute is mandatory.

Is there a registry (or at least a full list) of valid names?
Or did you mean "MIME type"?

5) In 12.2.2:

  format  This property is optional.  If defined, the value of the
      property is an array.  Each array element is an object which
      specifies information about one format of the media stream.  The
      object contains at least one property called name whose value is
      the subtype of the media format ([RFC4855]).

Here you say subtype, but your example later in the same section shows:

  In this case, session.connection.protocol.sip.media[0].type evaluates
  to "audio", session.connection.protocol.sip.media[0].direction to
  "recvonly" (i.e. the endpoint only receives media from the dialog -
  the endpoint does not send media to the dialog), and
  session.connection.protocol.sip.media[0].format[0].name evaluates to
  "audio/PCMU" and

I.e. I think this should be "PCMU", or you need to correct the definition above.

  session.connection.protocol.sip.media[0].format[0].rate evaluates to
  "8000".

6) In Section 12.4:

  |  | name="__reason">exit true      |

This doesn't seem to match your definition of how "expr" is converted to

7) In 4.2.6.1:

 
   
   
   
      recording
     

     

You have a problem here, as your data is base-64 encoded, yet you don't specify anywhere in the payload that that is being the case. And there is no text saying when this is implied for particular MIME types.

So I think this is missing information about Content-Transfer-Encoding.
It looks like Content-Transfer-Encoding (pick your attribute name) needs to be another attribute to "param".

     
   
   
   
 

8) In 4.6.10:

  A string formated as a IANA MIME media type ([MIME.mediatypes]).

Firstly, I think this should also point to exact ABNF for this.
It is also not clear if Content-type parameters are allowed in this field. Some of your uses of this type imply so, while other don't.

For MIME type/subtype ABNF, please reference Section 4.2 of RFC 4288.
I would also encourage you to specify proper ABNF for this production (and to reference "type-name" and "subtype-name" from Section .2 of RFC 4288)

9) In 4.3.1.4:

  append:  indicates whether recorded data is appended or not to a
      recording location if a resource already exists.  A valid value is
      a boolean (see Section 4.6.1).  A value of true indicates that
      recorded data is appended to the existing resource at a recording
      location.  A value of false indicates that recorded data is to
      overwrite the existing resource.  The attribute is optional.  The
      default value is false.

How is append/overwrite mapped to underlying protocol being used?
In particular, I think this is underspecified in case of HTTP.

10) In 12:

This section and its subsections are using RFC 2119 language, so they
look normative for somebody who chooses to implement VoiceXML as a dialog
language. This in its turn means that some of the following references:

  [RFC4627]  Crockford, D., "The application/json Media Type for
              JavaScript Object Notation (JSON)", RFC 4627, July 2006.

  [VXML20]  McGlashan, S., Burnett, D., Carter, J., Danielsen, P.,
              Ferrans, J., Hunt, A., Lucas, B., Porter, B., Rehor, K.,
              and S. Tryphonas, "Voice Extensible Markup Language
              (VoiceXML) Version 2.0", W3C Recommendation, March 2004.

  [VXML21]  Oshry, M., Auburn, RJ., Baggia, P., Bodell, M., Burke, D.,
              Burnett, D., Candell, E., Carter, J., McGlashan, S., Lee,
              A., Porter, B., and K. Rehor, "Voice Extensible Markup
              Language (VoiceXML) Version 2.1", W3C Recommendation,
              June 2007.

  [VXML30]  McGlashan, S., Auburn, RJ., Baggia, P., Barnett, J.,
              Bodell, M., Burnett, D., Carter, J., Oshry, M., Rehor, K.,
              Young, M., and R. Hosn, "Voice Extensible Markup Language
              (VoiceXML) Version 3.0", W3C Working Draft, December 2008.

are Normative (they are currently Informative).

11) BCP 18 (RFC 2277) requires that any human readable text is explicitly or implicitly tagged with a language tag. This affects the following fields in your document:

4.2.4. 

  reason:  string specifying a reason for the response status.  The
      attribute is optional.  There is no default value.

4.2.5.1. 

  reason:  a textual description which the MS SHOULD use to provide a
      reason for the status code; e.g. details about an error.  A valid
      value is a string (see Section 4.6.6).  The attribute is optional.
      There is no default value.

4.4.2. 

  reason:  string specifying a reason for the status.  The attribute is
      optional.

4.4.2.2.5.1. 

  desc:  a string providing some textual description of the type and
      format.  The attribute is optional.

Language tagging is missing here

  :  element with a desc attribute (optional description)

As above

      and a content model describing a supported format in the
      format attribute.  The element is optional.


I think the easiest way to address this would be to add xml:lang attribute to various identified places (and update the XML Schema accordingly), however other alternatives might be more suitable for you.
(See  for a bit more details)

Also note that some of the examples might have to be updated to show language tagging.

[Ballot comment]
4.2.2.2.1. 

  The  element is used to specify the region within a video
  layout where a video media stream is displayed.

What is "region"? Is this the same as DVD region?


4.3.1.1.1. 

  A  element has the following attributes:

  value:  specifies the string to be rendered.  A valid value is a
      string (see Section 4.6.6).  The attribute is mandatory.

  type:  specifies the type to use for rendering.  A valid value is a
      string (see Section 4.6.6).  The attribute is mandatory.

  format:  specifies format information to use in conjunction with the
      type for the rendering.  A valid value is a string (see
      Section 4.6.6).  The attribute is optional.  There is no default
      value.

Are these defined somewhere in more details?

  For example, the MS could support  type/format combinations
  such as:

Is this the complete list?

4.6.4.  Non-Negative Integer

  The value space of non-negative integer is the infinite set
  {0,1,2,...}.

(And the same comment for positive integers)
Is making this unbounded truly necessary? This might be a burden on
implementations and many (most?) will limit it anyway.

4.6.11.  Language Identifier

  A language identifier labels information content as being of a
  particular human language variant.  Following the XML specification
  for language identification [XML], a legal language identifier is
  identified by a RFC566 ([RFC5646]) and RFC4647 ([RFC4647]) code where

typo: RFC5646

  the language code is required and a country code or other subtag
  identifier is optional.

[Ballot discuss]
I think the document is in a pretty good shape despite the length of my comments.

Below are some blocking comments that need to be discussed and possibly addressed before I can recommend approval of this document:

1) In Section 4:

  The MS MUST
  support one or more schemes using communication protocols suitable
  for fetching resources (e.g.  HTTP).

I don't think this is good enough for interoperability. You should specify a mandatory to implement protocol for fetching resources.
I suggest you mandate use of HTTP and HTTPS. (The latter is important for providing data confidentiality)

The same issue is relevant in section 4.3.1.4 - a mandatory to implement protocol for recording data.

2) Use of authentication information in URIs in the "src" attribute (in multiple sectons):

E.g. in Section 4.2.1:

  src:  specifies the location of an external dialog document to
      prepare.  A valid value is a URI (see Section 4.6.9) including
      authentication information if defined by the URI scheme (e.g.
      basic access authentication in HTTP).

Is this supposed to include the password as well?
If yes, how can this be represented in URIs?
If not, where is this information coming from?

3) Multiple typos in XML examples (I haven' checked all, but spotted some problems):

4.2.2.1:

 
   
   

     
     
     
     

I think "rewkey" should be "rwkey"

   
   
   
   
   
 

4.3.1.1.3:

 
 
   

     
     
       
        ".

     
     
   
   
 


4.3.1.1.3.1:

 
 
   

     
     
       
         
         
         
         
       
        "

     
     
   
   
 

4) In 4.2.2.2:

  The  element has the following attributes:

  media:  a string indicating the type of media associated with the
      stream.  The following values MUST be used for common types of
      media: "audio" for audio media, and "video" for video media.  The
      attribute is mandatory.

Is there a registry (or at least a full list) of valid names?
Or did you mean "MIME type"?

5) In 12.2.2:

  format  This property is optional.  If defined, the value of the
      property is an array.  Each array element is an object which
      specifies information about one format of the media stream.  The
      object contains at least one property called name whose value is
      the subtype of the media format ([RFC4855]).

Here you say subtype, but your example later in the same section shows:

  In this case, session.connection.protocol.sip.media[0].type evaluates
  to "audio", session.connection.protocol.sip.media[0].direction to
  "recvonly" (i.e. the endpoint only receives media from the dialog -
  the endpoint does not send media to the dialog), and
  session.connection.protocol.sip.media[0].format[0].name evaluates to
  "audio/PCMU" and

I.e. I think this should be "PCMU", or you need to correct the definition above.

  session.connection.protocol.sip.media[0].format[0].rate evaluates to
  "8000".

6) In Section 12.4:

  |  | name="__reason">exit true      |

This doesn't seem to match your definition of how "expr" is converted to

7) In 4.2.6.1:

 
   
   
   
      recording
     

     

You have a problem here, as your data is base-64 encoded, yet you don't specify anywhere in the payload that that is being the case. And there is no text saying when this is implied for particular MIME types.

So I think this is missing information about Content-Transfer-Encoding.
It looks like Content-Transfer-Encoding (pick your attribute name) needs to be another attribute to "param".

     
   
   
   
 

8) In 4.6.10:

  A string formated as a IANA MIME media type ([MIME.mediatypes]).

Firstly, I think this should also point to exact ABNF for this.
It is also not clear if Content-type parameters are allowed in this field. Some of your uses of this type imply so, while other don't.

For MIME type/subtype ABNF, please reference Section 4.2 of RFC 4288.
I would also encourage you to specify proper ABNF for this production (and to reference "type-name" and "subtype-name" from Section .2 of RFC 4288)

9) In 4.3.1.4:

  append:  indicates whether recorded data is appended or not to a
      recording location if a resource already exists.  A valid value is
      a boolean (see Section 4.6.1).  A value of true indicates that
      recorded data is appended to the existing resource at a recording
      location.  A value of false indicates that recorded data is to
      overwrite the existing resource.  The attribute is optional.  The
      default value is false.

How is append/overwrite mapped to underlying protocol being used?
In particular, I think this is underspecified in case of HTTP.

10) In 12:

This section and its subsections are using RFC 2119 language, so they
look normative for somebody who chooses to implement VoiceXML as a dialog
language. This in its turn means that some of the following references:

  [RFC4627]  Crockford, D., "The application/json Media Type for
              JavaScript Object Notation (JSON)", RFC 4627, July 2006.

  [VXML20]  McGlashan, S., Burnett, D., Carter, J., Danielsen, P.,
              Ferrans, J., Hunt, A., Lucas, B., Porter, B., Rehor, K.,
              and S. Tryphonas, "Voice Extensible Markup Language
              (VoiceXML) Version 2.0", W3C Recommendation, March 2004.

  [VXML21]  Oshry, M., Auburn, RJ., Baggia, P., Bodell, M., Burke, D.,
              Burnett, D., Candell, E., Carter, J., McGlashan, S., Lee,
              A., Porter, B., and K. Rehor, "Voice Extensible Markup
              Language (VoiceXML) Version 2.1", W3C Recommendation,
              June 2007.

  [VXML30]  McGlashan, S., Auburn, RJ., Baggia, P., Barnett, J.,
              Bodell, M., Burnett, D., Carter, J., Oshry, M., Rehor, K.,
              Young, M., and R. Hosn, "Voice Extensible Markup Language
              (VoiceXML) Version 3.0", W3C Working Draft, December 2008.

are Normative (they are currently Informative).

11)

IANA comments:

IANA understands that some of the actions that would need to be
completed upon approval of this document depend on actions in other
Internet Drafts. Specifically, ietf-mediactrl-sip-control-framework.

Upon approval of this document IANA understands that it must complete
four actions.

First, in the Media Control Channel Framework Package sub-registry
created upon approval of ietf-mediactrl-sip-control-framework, a new
Control Channel Framework Package registration is to be created using
the template located in Section 8.1 of this document (specifically, the
mechanism for creating the new CCF Package Registration is located in
section 12.1 of ietf-mediactrl-sip-control-framework).

Second, IANA is to register a new URN sub-namespace in the IANA XML
registry located at http://www.iana.org/assignments/xml-registry
/ns.html. The namespace is urn:ietf:params:xml:ns:msc-ivr. The details
of the registration are provided in section 8.2 of the document.

Third, IANA is to register a new XML schema in the IANA XML registry
located at http://www.iana.org/assignments/xml-registry/schema.html.
The details of the registration are provided in section 8.3 of the
document and the schema is provided in section 5 of the document.

Fourth, IANA will register a new media type:

application/msc-ivr+xml

in the media type registry located at
http://www.iana.org/assignments/media-types/application/ using the
details provided in Section 8.4 of the document.

IANA understands that these four actions are the only ones it needs to
complete upon approval of the document.

IANA understands that some of the actions that would need to be
completed upon approval of this document depend on actions in other
Internet Drafts. Specifically, ietf-mediactrl-sip-control-framework.

IANA has two questions about the IANA Actions in this document. Upon
approval of this document IANA understands that it must complete four
actions.

First, in the Media Control Channel Framework Package sub-registry
created upon approval of ietf-mediactrl-sip-control-framework, a new
Control Channel Framework Package registration is to be created using
the template located in Section 8.1 of this document.

Second, IANA is to register a new URN sub-namespace in the IANA XML
registry located at http://www.iana.org/assignments/xml-registry
/ns.html. The namespace is urn:ietf:params:xml:ns:msc-ivr. The details
of the registration are provided in section 8.2 of the document. IANA

IANA QUESTION: what are the id and registration template names to be
used for this sub-namespace registration?

Third, IANA is to register a new XML schema in the IANA XML registry
located at http://www.iana.org/assignments/xml-registry/schema.html.
The details of the registration are provided in section 8.3 of the
document and the schema is provided in section 5 of the document.

IANA QUESTION: what are id and filename for this registration?

Fourth, IANA will register a new media type:

application/msc-ivr+xml

in the media type registry located at
http://www.iana.org/assignments/media-types/application/ using the
details provided in Section 8.4 of the document.

IANA understands that these four actions are the only ones it needs to
complete upon approval of the document.

(1.a) Who is the Document Shepherd for this document? Has the
Document Shepherd personally reviewed this version of the
document and, in particular, does he or she believe this
version is ready for forwarding to the IESG for publication?

Spencer Dawkins is the document shepherd. I have personally reviewed this
version of the document, and it is ready to forward to the IESG for
publication.

(1.b) Has the document had adequate review both from key WG members
and from key non-WG members? Does the Document Shepherd have
any concerns about the depth or breadth of the reviews that
have been performed?

The document has had reviews by key WG members as well as RAI expert
review (by Ben Campbell) and early SECDIR review (by Donald Eastlake).

(1.c) Does the Document Shepherd have concerns that the document
needs more review from a particular or broader perspective,
e.g., security, operational complexity, someone familiar with
AAA, internationalization or XML?

No.

(1.d) Does the Document Shepherd have any specific concerns or
issues with this document that the Responsible Area Director
and/or the IESG should be aware of? For example, perhaps he
or she is uncomfortable with certain parts of the document, or
has concerns whether there really is a need for it. In any
event, if the WG has discussed those issues and has indicated
that it still wishes to advance the document, detail those
concerns here. Has an IPR disclosure related to this document
been filed? If so, please include a reference to the
disclosure and summarize the WG discussion and conclusion on
this issue.

None.

(1.e) How solid is the WG consensus behind this document? Does it
represent the strong concurrence of a few individuals, with
others being silent, or does the WG as a whole understand and
agree with it?

Strong consensus for publishing. This is one of two key control packages for
the entire working group.

(1.f) Has anyone threatened an appeal or otherwise indicated extreme
discontent? If so, please summarise the areas of conflict in
separate email messages to the Responsible Area Director. (It
should be in a separate email because this questionnaire is
entered into the ID Tracker.)

None.

(1.g) Has the Document Shepherd personally verified that the
document satisfies all ID nits? (See
http://www.ietf.org/ID-Checklist.html and
http://tools.ietf.org/tools/idnits/). Boilerplate checks are
not enough; this check needs to be thorough. Has the document
met all formal review criteria it needs to, such as the MIB
Doctor, media type and URI type reviews?

Checked with ID nits 2.11.05. The document generates a LOT of spurious nits,
because

- it uses square brackets to identify requirement labels, which look like
dangling references - but they aren't - and

- because the draft contains a "changes from previous versions" section with
a lot of section labels that look like (non-RFC 3330) IP addresses - but
they aren't - and

- because the draft includes XML attributes that look like (non-RFC 2606)
FQDNs - but they aren't.

All of these nits are spurious.

The document uses active tense in its 2119 boilerplate instead of the
passive voice most documents use.

(1.h) Has the document split its references into normative and
informative? Are there normative references to documents that
are not ready for advancement or are otherwise in an unclear
state? If such normative references exist, what is the
strategy for their completion? Are there normative references
that are downward references, as described in [RFC3967]? If
so, list these downward references to support the Area
Director in the Last Call procedure for them [RFC3967].

We do have normative and informative references. All normative references
are published except for the MEDIACTRL Control Framework (just submitted for
publication), and there are no down-refs.

(1.i) Has the Document Shepherd verified that the document IANA
consideration section exists and is consistent with the body
of the document? If the document specifies protocol
extensions, are reservations requested in appropriate IANA
registries? Are the IANA registries clearly identified? If
the document creates a new registry, does it define the
proposed initial contents of the registry and an allocation
procedure for future registrations? Does it suggest a
reasonable name for the new registry? See [RFC5226]. If the
document describes an Expert Review process has Shepherd
conferred with the Responsible Area Director so that the IESG
can appoint the needed Expert during the IESG Evaluation?

Yes.

(1.j) Has the Document Shepherd verified that sections of the
document that are written in a formal language, such as XML
code, BNF rules, MIB definitions, etc., validate correctly in
an automated checker?

The XML has been validated using the w3c xml schema tester and using
xerces-c.

(1.k) The IESG approval announcement includes a Document
Announcement Write-Up. Please provide such a Document
Announcement Write-Up? Recent examples can be found in the
"Action" announcements for approved documents. The approval
announcement contains the following sections:

Technical Summary

This document defines a Media Control Channel Framework Package for
Interactive Voice Response (IVR) dialog interaction on media
connections and conferences. The package defines dialog management
request elements for preparing, starting and terminating dialog
interactions, as well as associated responses and notifications.
Dialog interactions are specified in a dialog language. This package
defines a lightweight IVR dialog language (supporting prompt
playback, runtime controls, DTMF collect and media recording) and
allows other dialog languages to be used. The package also defines
elements for auditing package capabilities and IVR dialogs.

Working Group Summary

Nothing out of the ordinary happened in the WG to note.

Document Quality

This document has sufficient normative statements and examples for one
to create an implementation. There are at least four independent
implementations of the control package described by this document.

This document has been stable for several versions, with small changes in
each revision, discussed on the mailing list. Most of the recent changes
have been suggested based on implementer experience.