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

["McGlashan, Scott" <[e-mail]>]

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
>