Re: [Slim] Extended functionality for the real-time language negotiation

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

Brian,

Earlier we ran in circles around these functional requirements and their 
possible inclusion in the current draft.

Not this time.

I started to analyze what the mentioned functional extensions would 
mean, and tried to come up with possible ways to code them.

Since Dale in the review also recommended us to switch to use the syntax 
similar to the Accept-Language, I took that as one base for the 
extension alternatives.

That led to the three possible extension variants for each functional 
extension, and a brief analysis of them.

The analysis is valid both if we make them as extensions after 
publication of our initial draft, or if it is decided that one or both 
functionalities can be included now.

The planned extensions might be allowed to influence the current draft 
even if the extensions themselves are not included.

The conclusion of my analysis was then that it would be easier to create 
the extensions if the coding of the current functionality moved to the 
syntax similar to Accept-Language.

It is not going in circles to discuss and decide if we shall take the 
step to change the coding to satisfy both Dales' recommendations and my 
analysis.

Please look at the extension discussion below and comment which one you 
prefer, or propose yet other altenatives.


It is a separate discussion, but It is also true that I want to see the 
functional extensions included in the initial publication, and I do not 
see the value in publishing something without functions we know are 
needed. While we keep in discussing this I see projects moving on using 
private solutions for the functionality we discuss, causing risks for 
interoperability problems in the future. I think it is a failure to not 
solve the functional needs. They are real and urgent and solving them is 
the only politically correct way to act.


/Gunnar



Den 2017-03-10 kl. 19:46, skrev Brian Rosen:
> We seem to be running in circles.
>
> The work group has discussed the idea of indicating media & language 
> combination preferences and DECLINED, at this time to do that.  We 
> decided our first effort would be to label language preferences per 
> media, with no cross media preferences.  That doesn’t mean we won’t 
> ever do it.  It means our first document on SDP negotiation won’t 
> cover that case.
>
> Yet you keep trying to get it in the current document.
>
> I don’t want to revisit our decision, and I don’t want to see any 
> linkage between media in this document.  I accept there are 
> requirements to have such linkages, but think there are many. many 
> uses for a simpler mechanism such as what the current document discusses.
>
> If you want to write a draft that proposes an extension to the current 
> mechanism, please write it, and I’ll review it.  But I would like to 
> see this document published with the simple per-media preference.
>
> Brian
>
>
>> On Mar 10, 2017, at 1:25 PM, Arnoud van Wijk 
>> <[e-mail] 
>> <mailto:[e-mail]>> wrote:
>>
>> Hi Gunnar,
>>
>> I also prefer solution 1.2 and 2.2
>>
>> I like the use of q values here. I think that is better then adding a 
>> new attribute.
>>
>>
>> Good proposal.
>>
>>
>> /Arnoud
>>
>>
>>
>> On 07/03/2017 14:01, Gunnar Hellström wrote:
>>>
>>> This is a slightly improved extract from the summary of the LC 
>>> period for the real-time SLIM draft about two discussed 
>>> functionality extensions. (Some of the examples had copy-paste errors.)
>>>
>>> The intention is to discuss this topic as far as needed to decide if 
>>> any or both these functionality enhancements could go into the 
>>> current draft before publication, and if not included then decide if 
>>> any changes are required in the current draft in order to 
>>> accommodate for the extensions.
>>>
>>> (see the summary sent on March 4 for e.g. references to the other 
>>> summary points.
>>>
>>> ----------------------------------------------------------------------------------------------------------
>>>
>>> *n). Indication of preference between media, and of simultanous 
>>> versus alternative languages.*
>>>
>>> This is a summary of the remaining issues related to items e), f), 
>>> j) and m) above.
>>>
>>> Issue e) proposes changes to enable indication of preference for 
>>> language in different media.
>>> Issue f) requests possibility to indicate request or offering of 
>>> text captions of spoken language.
>>> Issue j) proposes use of the Accept-Language syntax, that could both 
>>> solve the functional needs
>>> of e) and f) and sort out the syntax and semantics problems of the 
>>> asterisk parameter.
>>> Issue m) just indicates that issue e) is not yet resolved.
>>>
>>> Randall has proposed to resolve the functional needs in a new draft, 
>>> and not accept the Accept-Language syntax.
>>> I have proposed a simple way to resolve issue e) - the preference 
>>> between media, at the same time improving the definition of the 
>>> semantics of the asterisk parameter.
>>> No real solution to issue f) - the simultaneity indication  has been 
>>> discussed.
>>> Issue j) - the proposal to use the Accept-Language syntax can 
>>> potentially be used to resolve issues e) and f).
>>>
>>>  Discussion:
>>> Issue e) says that there is a need to be able indicate which of a 
>>> set of language/media indications are more preferred alternatives 
>>> than others.
>>> Examples are:
>>> 1. A want to get written English in text, A can as a less preferred 
>>> alternative accept to get spoken English.  An answering party B who 
>>> can use text will then respond with written text and get good 
>>> satisfaction, while another answering user C without text capability 
>>> will answer in spoken English and have a possibility for a 
>>> reasonably successful call.
>>> Without this indication, the first answering party B may have seen 
>>> the spoken and written alternatives as true equal preference 
>>> alternatives and answered with spoken English that will result in 
>>> less satisfied users.
>>> 2. A Prefer to receive spoken language, and can accept to receive 
>>> text.   When answering party B can use spoken language, that will be 
>>> satisfied, otherwise written language will be used.
>>> 3. A Prefer to use spoken language in both directions, and can 
>>> accept to use sign language in video in both directions. Answering 
>>> party B has a clear indication of why both signed and written is 
>>> indicated and can answer according to its capabilities trying to 
>>> satisfy the preference for spoken language.
>>> 4. A Prefer to use  sign language in both directions and can accept 
>>> to use written language in both directions. Sign language users will 
>>> use sign language, others will use text.
>>> 5. Prefer to send sign language and receive text (deaf-blind user), 
>>> can accept to send text.  In a call with a person with similar 
>>> prefeences, text will be used both ways, otherwise sign one way and 
>>> text the other.
>>>
>>> etc.
>>>
>>> Issue f) requires a way to indicate use of captioning and other 
>>> situations where use of simultaneous languages in different 
>>> modalities are needed:
>>>
>>> 1. Preference for hearing spoken language and simultaneously read 
>>> written language in text. ( captioning) .   The time is here when 
>>> this can be provided automatically in some settings, but also 
>>> traditionally by a manned service.
>>> 2. Preference for hearing spoken language and simultaneously seeing 
>>> the speaker in video. (lip-reading).  Easily and naturally provided 
>>> once the need is known.
>>> 3. Preference for seeing sign language and simultaneously hear 
>>> spoken language in audio.  ( for multiple users at the terminal )    
>>> One of the streams is provided by an interpreter.
>>> 4. Preference for hearing spoken language and simultaneously view 
>>> written language in video. (captioning if we accept to specify text 
>>> as overlay on video, otherwise it is same as number 1.)
>>>
>>> Some of these can be acceptable also if just one of the 
>>> language/media combinations can be provided, but is much more 
>>> preferred if both can be provided together. In other cases it is 
>>> essential to get both simultaneously. There is a need to 
>>> differentiate in the indication that this preference for getting the 
>>> languages together is preferred.
>>>
>>> Alternative coding proposals:
>>> 1. Preference between language/modality
>>> 1.1 Based on draft -08, add the coding of an asterisk last in an 
>>> attribute to mean lower preference for a lanugage/media combination 
>>> than the one(s) without an asterisk.
>>> example
>>> m=audio
>>> a=hlang-recv:en*
>>> m=text
>>> a=hlang-recv:en
>>>
>>> Audio and text are alternatives and text preferred
>>>
>>> 1.2. Change to the Accept-Language syntax and let the q-values have 
>>> scope over the whole SDP.
>>>
>>>   m=video 51372 RTP/AVP 31 32
>>>   a=hlang-recv:ase;q=0.9
>>>   a=hlang-send:ase;q=0.9
>>>
>>>
>>>   m=text 49250 RTP/AVP 98,99
>>>   a=hlang-send:en;q=0.5,*;q=0.1
>>>   a=hlang-recv:en;q=0.5,*;q=0.1
>>>
>>> Sign language is higher preferred than text.
>>>
>>>   
>>>
>>>
>>>
>>> 1.3. Introduce a new a=modality attribute on media level, with 
>>> parameters: <modality>, <direction>, <preference>
>>> example:
>>>
>>> m=text
>>> a=modality:written,recv,hi
>>> a=hlang-recv:en*
>>> m=audio
>>> a=modality:spoken,recv,med
>>> a=hlang-recv:en*
>>>
>>>
>>>
>>> 2. Preference for simultaneous languages vs alternative languages:
>>>
>>> 2.1. Based on draft -08, add another notation to the use of the 
>>> asterisk, e.g. an optional character to be used together with the 
>>> asterisk to mark media that are wanted together. (ugly)   example:
>>>
>>> m=audio
>>> a=hlang-recv:en*$c
>>> m=text
>>> a=hlang-recv:en$c
>>>
>>> The $ is a simultaneity indication, the c is a groouping indicator 
>>> telling that all modalities marked with the $c are wanted together. 
>>> (we might be able to restrict the indication to just one set of 
>>> languages that are wanted simultaneously.
>>>
>>>
>>> 2.2. Use the Accept-Language syntax and add the usage rules that 
>>> q-values with less than .1 difference mean languages with a 
>>> preference to be used together. Higher differences indicate that 
>>> they are alternatives.  Thereby it is both possible to indicate 
>>> simultaneity and preference if the simultaneity cannot be satisfied.
>>>
>>>   m=audio 51372 RTP/AVP 0
>>>   a=hlang-recv:ase;q=0.5
>>>   a=hlang-send:ase;q=0.5
>>>
>>>
>>>   m=text 49250 RTP/AVP 98,99
>>>   a=hlang-send:en;q=0.51,*;q=0.1
>>>   a=hlang-recv:en;q=0.51,*;q=0.1
>>>
>>> The q-values differences are within 0.1 so it is a preference for getting both together, but if that is not possible, text is preferred.
>>>
>>>
>>> 2.3. Add to the new a=modality attribute a fourth, optional 
>>> parameter [simultaneity]   with value any single letter, indicating 
>>> a preference for having that modality simultaneously with another 
>>> modality indicated with the same value in the [simultaneity] 
>>> parameter.   Without this parameter, the modalities are alternatives.
>>>
>>> m=text
>>> a=modality:written,recv,hi,d
>>> a=hlang-recv:en*
>>> m=audio
>>> a=modality:spoken,recv,hi,d
>>> a=hlang-recv:en*
>>>
>>>
>>> *
>>> *
>>>
>>> ***Status: Not solved. Conclusion needed on how to handle these 
>>> issues e, f, and j,  both regarding which solution and what 
>>> procedure to take to apply it.*
>>>
>>> I have a slight preference for solution 1.2 and 2.2 ,
>>>
>>> Your views?
>>>
>>> Regards
>>> Gunnar
>>> -- 
>>> -----------------------------------------
>>> Gunnar Hellström
>>> Omnitor
>>> [e-mail]
>>> [phone]
>>>
>>>
>>> _______________________________________________
>>> SLIM mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/slim
>>
>> _______________________________________________
>> SLIM mailing list
>> [e-mail] <mailto:[e-mail]>
>> https://www.ietf.org/mailman/listinfo/slim
>
>
>
> _______________________________________________
> SLIM mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/slim

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