[MEDIACTRL] Fwd: Alexey Melnikov's DISCUSS and COMMENT on draft-ietf-mediactrl-ivr-control-package-09

[Eric Burger <[e-mail]>]

Begin forwarded message:

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

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

4.2.5.1.  <dialogexit>

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

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

4.4.2.2.5.1.  <variabletype>

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

Language tagging is missing here

  <format>:  element with a desc attribute (optional description)

As above

     and a content model describing a supported format in the <variable>
     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 <http://trac.tools.ietf.org/group/iesg/trac/wiki/TypicalAppsAreaIssues> for a bit more details)

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



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