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

[Eric Burger <[e-mail]>]

I meant this is what I think we should do.

On Dec 15, 2010, at 12:48 PM, McGlashan, Scott wrote:

> 2 points.
> 
> 1. Don't get Keith's point about 'text making the references needs to
> redrafted'. In discussion with Alexey, I proposed not to add VoiceXML 3.0
> as a normative reference (VoiceXML is already well covered by references
> to 2.0 and 2.1), but to make RFC 4627 normative since it is mandatory if
> and only if a media server chooses to support VoiceXML as a dialog
> language. This is a followup to Alexey's previous comments about making
> references normative if they are required for a feature even if that
> feature is optional.
> 
> 2. On the language tag issue. Having read RFC 2277, I'm inclined to agree
> that we should include
> language tags in the elements that Alexey indicates (both mixer and ivr).
> RFC 2277 Section 4.2 states:
> 
>   Protocols that transfer text MUST provide for carrying information
>   about the language of that text.
> 
> The language tag - xml:lang - would be added as an optional attribute of
> the relevant XML elements (and the xml schema updated). If a value is
> specified it is governed by BCP 47 (which obsoletes RFC 4646, RFC 3066,
> RFC 1766). The attribute would have a default value of "i-default". RFC
> 2277 Section 4.5:
> 
>   When human-readable text must be presented in a context where the
>   sender has no knowledge of the recipient's language preferences (such
>   as login failures or E-mailed warnings, or prior to language
>   negotiation), text SHOULD be presented in Default Language.
> 
>   Default Language is assigned the tag "i-default" according to the
>   procedures of RFC 1766. It is not a specific language, but rather
>   identifies the condition where the language preferences of the user
>   cannot be established.
> 
> 
>   Messages in Default Language MUST be understandable by an English-
>   speaking person, since English is the language which, worldwide, the
>   greatest number of people will be able to get adequate help in
>   interpreting when working with computers.
> 
> 
> I interpret this to mean that if an implementation wants to localize the
> descriptive tags of protocol elements then they can do so by explicitly
> setting the xml:lang attribute. If the xml:lang is not specified (e.g. the
> MS has no idea of the language preferences of the AS user), then (a) there
> is no syntax change required for the current protocol messages, and (b)
> the descriptive text can be in English as our examples. I propose to not
> update any examples, since the i-default value in the schema is
> sufficient.  
> 
> I can also update our definition of language identifier to also reference
> BCP 47 (which includes RFC 5646).
> 
> Is this acceptable? I'd like get these specs wrapped up  ..
> 
> Thanks
> 
> Scott
> 
> 
> On 07/12/2010 18:14, "Eric Burger" <[e-mail]> wrote:
> 
>> 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
>> 
>