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

[Randall Gellens <[e-mail]>]

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:

>  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 
>> <<mailto:[e-mail]>[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
>>>  <mailto:[e-mail]>[e-mail]
>>>  [phone]
>>>
>>>
>>>  _______________________________________________
>>>  SLIM mailing list
>>>  <mailto:[e-mail]>[e-mail]
>>> 
>>> <https://www.ietf.org/mailman/listinfo/slim>https://www.ietf.org/mailman/listinfo/slim
>>>
>>
>>  _______________________________________________
>>  SLIM mailing list
>>  <mailto:[e-mail]>[e-mail]
>>  https://www.ietf.org/mailman/listinfo/slim
>>
>
>
>  _______________________________________________
>  SLIM mailing list
>  [e-mail]
>  https://www.ietf.org/mailman/listinfo/slim


-- 
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.