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

From: Gunnar Hellström <[email-masked]>
Date: Tue, 7 Mar 2017 23:01:32 +0100

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
[email-masked]
+46 708 204 288

---

From: Arnoud van Wijk <[email-masked]>
Date: Fri, 10 Mar 2017 10:25:46 -0800

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:
> 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.
>
> Randall has proposed to resolve the functional needs in a new draft, 
> and not accept the Accept-Language syntax.
> 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:
> 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.
> 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.
> 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.
>
> 2. Preference for hearing spoken language and simultaneously seeing 
> the speaker in video.   (lip-reading).  Easily and naturally provided 
> once the need is known.
> language in audio.  ( for multiple users at the terminal )    One of 
> the streams is provided by an interpreter.
> 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.
>
> 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
>
> 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.
>
>
> 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
>
>
> 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
> _______________________________________________
> SLIM mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/slim

---

From: Brian Rosen <[email-masked]>
Date: Fri, 10 Mar 2017 13:46:12 -0500

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 <[email-masked]> wrote:
> 
> Hi Gunnar,
> 
> I like the use of q values here. I think that is better then adding a new attribute. 
> 
> Good proposal.
> 
> 
> /Arnoud
> 
> 
>> 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.
>> 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.
>> 
>> 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
>> 
>> 1.2. Change to the Accept-Language syntax and let the q-values have scope over the whole SDP.    
>> 1.3. Introduce a new a=modality attribute on media level, with parameters: <modality>, <direction>, <preference>     
>> example:
>> m=text
>> 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
>> 
>> 
>> 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
>> 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.
>> 
>> [email-masked] <mailto:[email-masked]>
>> +46 708 204 288
>> 
>> 
>> [email-masked] <mailto:[email-masked]>
>> https://www.ietf.org/mailman/listinfo/slim <https://www.ietf.org/mailman/listinfo/slim>
>

---

From: Gunnar Hellström <[email-masked]>
Date: Fri, 10 Mar 2017 23:54:02 +0100

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:
> 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.
>
> 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 
>> <[email-masked] 
>> <mailto:[email-masked]>> wrote:
>>
>> Hi Gunnar,
>>
>>> 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.)
>>>
>>> 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.
>>>
>>> *n). Indication of preference between media, and of simultanous 
>>> versus alternative languages.*
>>>
>>> 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:
>>> 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.
>>> 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.
>>> situations where use of simultaneous languages in different 
>>> modalities are needed:
>>>
>>> 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.
>>> 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.
>>> 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.
>>>
>>> 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
>>>
>>>
>>> 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
>>> ***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.*
>>>

---

From: Randall Gellens <[email-masked]>
Date: Mon, 13 Mar 2017 16:45:51 -0700

I agree with Brian.  The draft defines a very 
simple mechanism, as agreed in the WG.  The draft 
has been through WG discussion, WG last call, and 
IETF last call.  I would object to reopening the 
draft to add q-values or anything else.

We can advance the current draft and start work 
on a more complex mechanism.  This would mean we 
have something that is simple and useful 
published.  Or we can revert the draft back into 
the WG, and spend months discussing it.  Not only 
would this needlessly add major delay to the 
draft, but there is a real risk that we all get 
sick of it and the AD shuts down the WG.

At 1:46 PM -0500 3/10/17, Brian Rosen wrote:

>  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.
>
>  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
>
>
>> <<mailto:[email-masked]>[email-masked]> 
>> wrote:
>>
>>  Hi Gunnar,
>>
>>>  This is a slightly improved extract from the 
>>> summary of the LC period for the real-time 
>>> SLIM draft about two discussed functionality 
>>>  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 
>>>  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.
>>>  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 
>>>  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 
>>>  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.
>>>
>>>  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 
>>>  1.2. Change to the Accept-Language syntax and 
>>> let the q-values have scope over the whole 
>>> SDP.   
>>>
>>>  1.3. Introduce a new a=modality attribute on 
>>> media level, with parameters: <modality>, 
>>> <direction>, <preference>    
>>>  example:
>>>
>>>  m=text
>>>  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 
>>>  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
>>>
>>>
>>>  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 
>>>  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.
>>>
>>>  <mailto:[email-masked]>[email-masked]
>>>  +46 708 204 288
>>>
>>>
>>>  <mailto:[email-masked]>[email-masked]
>>> 
>>> <https://www.ietf.org/mailman/listinfo/slim>https://www.ietf.org/mailman/listinfo/slim
>>>
>>
>>  <mailto:[email-masked]>[email-masked]

-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly selected tag: ---------------
You never finish a program, you just stop working on it.

---

From: Natasha Rooney <[email-masked]>
Date: Tue, 14 Mar 2017 11:02:02 +0000

Myself and Bernard are discussing this situation currently in an effort to solve the outstanding issues and get the draft pushed through. We have heard opinions from a number of people, which is great. We’ll get back to everyone shortly on how we will proceed.

Natasha Rooney | Internet Engineering Director | Internet and Web Team | Technology | GSMA | [email-masked]<mailto:[email-masked]> | +44 (0) 7730 219 765 | @thisNatasha | Skype: [email-masked]<mailto:[email-masked]>

On 13 Mar 2017, at 23:45, Randall Gellens <[email-masked]<mailto:[email-masked]>> wrote:

I agree with Brian.  The draft defines a very simple mechanism, as agreed in the WG.  The draft has been through WG discussion, WG last call, and IETF last call.  I would object to reopening the draft to add q-values or anything else.

We can advance the current draft and start work on a more complex mechanism.  This would mean we have something that is simple and useful published.  Or we can revert the draft back into the WG, and spend months discussing it.  Not only would this needlessly add major delay to the draft, but there is a real risk that we all get sick of it and the AD shuts down the WG.

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.

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 <<mailto:[email-masked]>[email-masked]<mailto:[email-masked]>> wrote:

Hi Gunnar,

Good proposal.

/Arnoud

 Discussion:

etc.

1.3. Introduce a new a=modality attribute on media level, with parameters: <modality>, <direction>, <preference>     example:

m=text

m=audio
a=hlang-recv:en*$c
m=text
a=hlang-recv:en$c

 m=audio 51372 RTP/AVP 0
 a=hlang-recv:ase;q=0.5
 a=hlang-send:ase;q=0.5

m=text

Your views?

Regards
Gunnar
--
-----------------------------------------
Gunnar Hellström
Omnitor
<mailto:[email-masked]>[email-masked]<mailto:[email-masked]>
+46 708 204 288

_______________________________________________
SLIM mailing list
<mailto:[email-masked]>[email-masked]<mailto:[email-masked]>
<https://www.ietf.org/mailman/listinfo/slim>https://www.ietf.org/mailman/listinfo/slim

_______________________________________________
SLIM mailing list
<mailto:[email-masked]>[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/slim

_______________________________________________
SLIM mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/slim

-------------- Randomly selected tag: ---------------

_______________________________________________
SLIM mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/slim

This email and its attachments are intended for the above named only and may be confidential. If they have come to you in error you must take no action based on them, nor must you copy or show them to anyone; please reply to this email or call +44 207 356 0600 and highlight the error.

---

From: Gunnar Hellström <[email-masked]>
Date: Tue, 14 Mar 2017 23:28:52 +0100

Another method than the ones proposed below in 2.1,  2.2 and 2.3 for 
satisfying the request for coding of captions could be to use the -t subtag.

This is a discussion independent of the issue if we include a solution 
on this need in the current draft or another.

-t means transformed content. Its use is specified in RFC 6497. The 
format is approximately  [presented language]-t-[source language]

Application rules could be defined for the use of -t.

A proposal:  -t indicates that the content is transformed from a source. 
That makes it possible to produce it approximately simultaneously with 
the source. Thus from a sender, the indication of a language with -t 
subtag indicates a preparedness to provide this language simultaneously 
with languages in other media. From a receiver, it indicates a 
preference for receiving this language simultaneously with any language 
provided in other media.

When -t subtag is not included. it means that languages in different 
media for the same direction are instead alternatives to select from

When the language indicated as source in a -t subtag appears in another 
media in the same direction, it indicates that both the source language 
and the transformed language can be provided together or are desired 
together.

Captioning of spoken language is one example for use of this indication.

Captioning with translation from another spoken language is another 
similar use.

Spoken interpretation of a sign language is another use, when there is a 
preference to both see the signing person and have the spoken language 
interpretation in audio.

Regards

Gunnar

Den 2017-03-10 kl. 23:54, skrev Gunnar Hellström:
>
> Brian,
>
> Earlier we ran in circles around these functional requirements and 
> their possible inclusion in the current draft.
>
> Not this time.
>
> 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.
>
> 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.
>
> 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
>
>
>
>> 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
>>
>>
>>>> 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 
>>>> Randall has proposed to resolve the functional needs in a new 
>>>> draft, and not accept the Accept-Language syntax.
>>>> satisfaction, while another answering user C without text 
>>>> capability will answer in spoken English and have a possibility for 
>>>> a reasonably successful call.
>>>> text.   When answering party B can use spoken language, that will 
>>>> be satisfied, otherwise written language will be used.
>>>> to use written language in both directions. Sign language users 
>>>> will use sign language, others will use text.
>>>> spoken language in audio.  ( for multiple users at the terminal 
>>>> )    One of the streams is provided by an interpreter.
>>>> differentiate in the indication that this preference for getting

---

From: Gunnar Hellström <[email-masked]>
Date: Wed, 15 Mar 2017 07:46:01 +0100

This is an amended overview of possible solutions to the functionality 
extensions for the slim real-time draft.

It includes the alternative to use the language subtag -t- to indicate 
transformed language and thereby enable simultaneity.

The selected solutions can be included in the current draft or specified 
in a separate draft. If it is specified in a separate draft, the current 
draft needs to be checked and possibly adjusted so that it allows the 
selected syntax of the extensions.

The letters e) f) etc refer to the summary of issues from LC.

*Indication of preference between media, and of simultanous versus 
alternative languages.*

  Discussion:
Issue e) says that there is a need to be able to indicate which of a set 
of language/media indications are more preferred alternatives than others.
Examples are:
1. A user 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. A prefer to send sign language and receive text (deaf-blind user) and 
can accept to send text.  In a call with a person with similar 
preferences, text will be used both ways, otherwise sign one way and 
text the other.

etc.

Alternative coding proposals:
1. Preference between modalities
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 where audio and text are alternatives and text preferred
m=audio
a=hlang-recv:en*
m=text
a=hlang-recv:en

Example where sign language is higher preferred than text.

example:

m=text

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 or without 
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 grouping 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 for the hlang attributes 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

2.3. Add to the new a=modality attribute from solution 1.3 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. 
Use this solution together with solution 1.3

Example: Indicate that written English and spoken English are desired 
together but the call shall not be denied if that combination is not 
possible, and then written English is preferred.

m=text

The "d" is a grouping identifier.

2.4. Use the -t- subtag for transformed content on a language indication 
defined in RFC 6497 as an indication that this language can be provided 
or is desired together with a language in another modality. Use this 
indication together with solution 1.1

Example: Indicate that written English and spoken English are desired 
together and written English expected to be transformed.  but the call 
shall not be denied if that combination is not possible, and then 
written English is preferred.

m=text
a=hlang-recv:en-t-en
m=audio
a=hlang-recv:en*

The -t- indicated with the -recv direction shall not be understood that 
the indicated language needs to be transformed. It is just an 
expectation that enables it to be provided simultaneously.

My judgement of the alternatives:
I have a slight preference for solutions 1.2 and 2.2 because they are 
logically cleanest , but they require that we accept the LC review 
proposal to move to the Accept-Language syntax.
1.1 and 2.4 are easily added to the syntax of the current draft and have 
sufficient functionality for most cases.
1.3 and 2.3 cause more work and longer SDP
2.1 is ugly and kept here just for reference.

Gunnar