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

[Eric Burger <[e-mail]>]

Agreed. 

Any other comments on Alexey's comments? Come on folks, we are almost DONE!!!!


On Nov 28, 2010, at 4:59 PM, DRAGE, Keith (Keith) wrote:

> 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).
> This sounds to me like the text making the references needs to be redrafted, rather than making the references normative.
> 
> Surely this sort of thing is more example of how one might use the control package in a particular way to implement some things.
> 
> Keith
> 
> From: [e-mail] [mailto:[e-mail]] On Behalf Of Eric Burger
> Sent: Saturday, November 27, 2010 6:32 PM
> To: [e-mail]
> Subject: [MEDIACTRL] Fwd: Alexey Melnikov's DISCUSS and COMMENT on draft-ietf-mediactrl-ivr-control-package-09
> 
> 
> 
> 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.
> 
> _______________________________________________
> MEDIACTRL mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mediactrl
> Supplemental Web Site:
> http://www.standardstrack.com/ietf/mediactrl