Re: [Slim] IETF last call for draft-ietf-slim-negotiating-human-language (Section 5.4)

[Gunnar Hellström <[e-mail]>]

Randall,

I prefer that you wait for conclusion on the topic of "silly states".

And I agree with Bernard that we should (and can) be normative and 
explicit in how to interpret all the unusual combinations.

/Gunnar


Den 2017-02-13 kl. 23:26, skrev Randall Gellens:
> At 11:06 AM -0800 2/13/17, Bernard Aboba wrote:
>
>>  Looking over Section 5.4, it seems to me that the title "Silly 
>> States" may not be appropriate, because it mixes discussion of 
>> combinations of media and language that have an "undefined" meaning 
>> with combinations for which normative guidance can be provided  So 
>> rather than having a single "Silly States" section, perhaps we can 
>> have a section on "Undefined States" (for those combinations which 
>> have an undefined meaning) provide normative guidance on defined 
>> combinations elsewhere.
>>
>>
>> <https://tools.ietf.org/html/draft-ietf-slim-negotiating-human-language-06#section-5.4>5.4. 
>> Silly States
>>
>>
>>
>>     It is possible to specify a "silly state" where the language
>>     specified does not make sense for the media type, such as specifying
>>     a signed language for an audio media stream.
>>     An offer MUST NOT be created where the language does not make sense
>>     for the media type.  If such an offer is received, the receiver MAY
>>     reject the media, ignore the language specified, or attempt to
>>     interpret the intent (e.g., if American Sign Language is specified
>>     for an audio media stream, this might be interpreted as a desire to
>>     use spoken English).
>>
>>     A spoken language tag for a video stream in conjunction with an 
>> audio
>>     stream with the same language might indicate a request for
>>     supplemental video to see the speaker.
>>
>>  [BA] Rather than using terms like "might" for combinations that 
>> could have a
>>  defined meaning, I would like to see the specification provide 
>> normative
>>  language on these use cases. In particular, I would like the 
>> specification to describe:
>>
>>  a. What it means when a spoken language tag is included for a video 
>> stream.
>>  Is this to be interpreted as a request for captioning?
>>  b. What it means when a signed language tag is included for an audio 
>> stream.
>>  Is the meaning of this "undefined" and if so, should it be ignored?
>>  c. What it means when a signed language tag is included for a text 
>> stream.
>>
>>  If some of these scenarios are not defined, the specification can say
>>  "this combination does not have a defined meaning" or something like 
>> that.
>
> I will change the section title to "Undefined Combinations" and 
> replace the text with:
>
>    Specifying a non-signed language tag for a video media stream, or a
>    signed language tag for a non-video media stream, is not defined.  An
>    offer with such a combination SHOULD NOT be created.  If such an
>    offer is received, the receiver MAY ignore the language specified.
>
> I think this retains the intent of the old section while avoiding 
> wading into the unclear issue of intent of such combinations.
>

-- 
-----------------------------------------
Gunnar Hellström
Omnitor
[e-mail]
[phone]