Subject: Re: [Slim] Seeking rough consensus for draft-ietf-slim-negotiating-human-language

From: Gunnar Hellström <[email-masked]>
Date: Thu, 9 Jun 2016 00:18:45 +0200

I would like to have some acceptance for the needs expressed by me, 3GPP 
and ETSI.

That is:

A simple mechanism to specify preference for language within the session 
instead of only per media. ( clearly required by 3GPP TS 22.228 )

A simple mechanism to tell when the most desirable outcome is to be 
provided with two languages/modalities together rather than the general 
case when one selected language for the main language communication is 
sufficient.

I have provided some solutions and simplified compromises to solve these 
needs in the most limited fashion that also satisfies most applications.

I have seen many responses diving into discussions of media acceptance 
and media negotiation depending on language negotiation outcome. I think 
it would be good to clarify that the intention of language specification 
is not primarily to support offer/answer decisions on media session 
establishment, but rather for application support and user guidance.

It is quite similar in level to the intended use of the SDP Content  
attribute specified in RFC 4796.

I see a clear risk that implementations hoping for progress in SLIM as 
promising sign that a solution is on its way will lose the hope and 
cause fragmentation by selecting various solutions based on different 
existing specifications complemented by coding assumptions.

Can we move on and have a new version done well in time before the 
coming IETF meeting? Also including the promised and proposed 
modifications of other kinds?

/Gunnar

Den 2016-05-17 kl. 18:05, skrev Brian Rosen:
> Like Randall, I want to stay away from a linkage between what 
> languages you prefer and what media you are offering.

>
> I want to stay with the long standing SDP negotiation that you offer 
> media you want to use, and and or all of that media can be accepted.
>
> I want our work to build on that, not change it, so that we can 
> indicate, for the media accepted, what language is preferred.
>
> I further don’t want to link a preference of language on one media to 
> the preference of language on another media.   I want them 
> independent: if audio and text are offered and answered, then language 
> on audio is specified, and language on text is specified, and those 
> don’t interact.
>
> I think living with those restrictions will make implementations 
> easier, and won’t limit use much.
>
> Adding more complexity at this point is, I think, not worth it.
>
> Brian
>
>> On May 17, 2016, at 2:01 AM, Gunnar Hellström 
>> <[email-masked] <mailto:[email-masked]>> wrote:
>>
>> Randall,
>>
>> Can you accept that our goal is to select the most appropriate 
>> language(s) for the call?
>>
>> This includes providing guidance to the answering part so that the 
>> answer can be made in the most appropriate language(s).
>>
>> That is stated in the charter:
>>
>> "While the two use cases are in different contexts (real time and
>> non-real-time), the fundamental goal is the same: to enable selection of
>> the best-fit language(s) for a specific situation."
>>
>> It is not sufficient to use the indications to select which media 
>> shall be enabled, and then let the users sort out which language to use.
>>
>> The user needs guidance if it is most appropriate to start the 
>> conversation in voice, sign language or text or a combination of 
>> these modalities. If not, the call will start with confusion about 
>> what is the most efficient means for them to communicate.
>>
>> That is why the preference indication needs to have:
>>
>> a) a common scope over all media, and
>>
>> b) an indication if two modalities simultaneously are desired for 
>> reception.
>>
>> Can we agree on that and move on to find a simple way of expressing 
>> these needs?
>>
>> /Gunnar
>>
>>
>>
>>
>> Den 2016-05-17 kl. 05:25, skrev Randall Gellens:
>>> At 8:28 PM -0600 5/16/16, Doug Ewell wrote:
>>>
>>>>  Except that there is still disagreement on whether the mechanism 
>>>> is needed for SLIM 1.0.
>>>
>>> And we have a call for consensus by the chairs.
>>>
>>
>> -- 
>> -----------------------------------------
>> Gunnar Hellström
>> Omnitor
>> [email-masked]
>> +46 708 204 288
>> _______________________________________________
>> SLIM mailing list
>> [email-masked] <mailto:[email-masked]>
>> https://www.ietf.org/mailman/listinfo/slim
>

-- 
-----------------------------------------
Gunnar Hellström
Omnitor
[email-masked]
+46 708 204 288