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

[Eric Burger <[e-mail]>]

Hello team...

On Dec 2, 2010, at 6:39 AM, Eric Burger wrote:

> 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
> 
> _______________________________________________
> MEDIACTRL mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/mediactrl
> Supplemental Web Site:
> http://www.standardstrack.com/ietf/mediactrl