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

[Natasha Rooney <[e-mail]>]

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 | [e-mail]<mailto:[e-mail]> | [phone] | @thisNatasha | Skype: [e-mail]<mailto:[e-mail]>

On 13 Mar 2017, at 23:45, Randall Gellens <[e-mail]<mailto:[e-mail]>> 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.

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]<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
<mailto:[e-mail]>[e-mail]<mailto:[e-mail]>
[phone]


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


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



_______________________________________________
SLIM mailing list
[e-mail]<mailto:[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.

_______________________________________________
SLIM mailing list
[e-mail]<mailto:[e-mail]>
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 [phone] and highlight the error.