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

From: Randall Gellens <[email-masked]>
Date: Sun, 17 Jul 2016 09:29:09 -0700

Hi Gunnar,

As I see it, you're asking for a higher-level 
capability rather than the lower-level 
language-per-media mechanism we've been working 
on.  Rather than force it into the current 
real-time draft, I suggest a new draft 
specifically for the functionality you want.  If 
the group agrees that this functionality is 
needed, and agrees on a proposed mechanism to 
accomplish it, it should be compatible with the 
current real-time draft, so the two wouldn't 
interfere at all.

--Randy

At 12:18 AM +0200 6/9/16, Gunnar Hellström wrote:

>  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 
>>> <<mailto:[email-masked]>[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
>>>  <mailto:[email-masked]>[email-masked]
>>>  +46 708 204 288
>>>  _______________________________________________
>>>  SLIM mailing list
>>>  <mailto:[email-masked]>[email-masked]
>>> 
>>> <https://www.ietf.org/mailman/listinfo/slim>https://www.ietf.org/mailman/listinfo/slim
>>>
>>
>
>  --
>  -----------------------------------------
>  Gunnar Hellström
>  Omnitor
>  <mailto:[email-masked]>[email-masked]
>  +46 708 204 288
>
>  _______________________________________________
>  SLIM mailing list
>  [email-masked]
>  https://www.ietf.org/mailman/listinfo/slim

-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly selected tag: ---------------
When in doubt, use brute force.
        --Ken Thompson

---

From: Gunnar Hellström <[email-masked]>
Date: Sun, 17 Jul 2016 22:56:49 +0200

Hi Randy,
Den 2016-07-17 kl. 18:29, skrev Randall Gellens:
> Hi Gunnar,
>
> As I see it, you're asking for a higher-level capability rather than 
> the lower-level language-per-media mechanism we've been working on.
Maybe, but the per-media mechanism does not align with how the humans 
think. The use of the media are not unrelated, so you need to say how 
the languages in different media relate even if you do not want to go 
the whole way to specify relative priority and grouping between 
languages in different media.
>   Rather than force it into the current real-time draft, I suggest a 
> new draft specifically for the functionality you want.  If the group 
> agrees that this functionality is needed, and agrees on a proposed 
> mechanism to accomplish it, it should be compatible with the current 
> real-time draft, so the two wouldn't interfere at all.
If we need to take that step, you must agree to complete the work to 
make the current draft clear on some points related to multiple language 
specifications. We started a main exchange under the title "[Slim] 
Wording about selection in 
draft-ietf-slim-negotiating-human-language-01" where you agreed to do 
something to a few fuzzy places in the draft, but we never agreed on 
suitable wording. The mail thread ended on April 10 without a conclusion 
on suitable wording.

Without that, we have no firm ground for further work.

An example is the current wording in 6.2:
"

Clients acting on behalf of end users are expected to set one or both

'humintlang-send' and 'humintlang-recv' attributes on each media

stream primarily intended for human communication in an offer when

placing an outgoing session."

A) In one use case a person prefers to use spoken English for the call, 
but want to express that a text conversation in English can be accepted 
as a less favoured alternative.

B) In another use case a person want to talk English, and need to 
receive text because of a limitation in hearing, but still has some use 
of getting English speech. The person can also accept to type instead of 
speaking, but would not really prefer that.

These use cases both result in a need to specify sending and receiving 
in English in both audio and text media.
It is only the preferences and urgency to use the different media that 
differs.

Do you mean that the current draft supports describing any of these use 
cases?
If so, which?

Or what would a specification of English in both directions for both 
audio and text mean? Would it mean that all four must be used 
simultaneously?

The discussion we were involved in up to 10 April was intended to get 
the wording in this area a bit more clear, but I do not think we get 
this completely clarified until we describe relative priority between 
languages in different modalities.

I am composing a presentation with issues in current draft, and some 
other topics.
Looking forward to the meeting and progress in Slim.

Gunnar

>>  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 
>>>  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.
>>>
>>>>  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).
>>>>
>>>>  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.
>>>>
>>>>  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
>>>>
>>>>
>>>>
>>>>
>>>>>>  Except that there is still disagreement on whether the mechanism 
>>>>>> is needed for SLIM 1.0.
>>>>>>
>>>>>

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

---

From: Bernard Aboba <[email-masked]>
Date: Mon, 18 Jul 2016 07:26:43 +0200

On Jul 17, 2016, at 22:56, Gunnar Hellström <[email-masked]> wrote:
> These use cases both result in a need to specify sending and receiving in English in both audio and text media. 
> It is only the preferences and urgency to use the different media that differs. 
> 
> Do you mean that the current draft supports describing any of these use cases?

[BA] The current draft enables the language capabilities for each media to be expressed and negotiated in each direction. This enables media preference to be expressed and implemented subsequently (either through conversation or by a yet unspecified mechanism).

> Or what would a specification of English in both directions for both audio and text mean? Would it mean that all four must be used simultaneously? 

[BA] It means that the capability to use those languages bidirectionally has been negotiated - no usage obligation. 

> The discussion we were involved in up to 10 April was intended to get the wording in this area a bit more clear, but I do not think we get this completely clarified until we describe relative priority between languages in different modalities. 
> 
> I am composing a presentation with issues in current draft, and some other topics. 
>>>  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 
>>> 
>>> 
>>> 
>>>>  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. 
>>>> 
>>>>>  On May 17, 2016, at 2:01 AM, Gunnar Hellström <<mailto:[email-masked]>[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). 
>>>>> 
>>>>>  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. 
>>>>> 
>>>>>  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 
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>>>>  Except that there is still disagreement on whether the mechanism is needed for SLIM 1.0.
>>>>>>

---

From: Gunnar Hellström <[email-masked]>
Date: Mon, 18 Jul 2016 13:40:57 +0200

Den 2016-07-18 kl. 07:26, skrev Bernard Aboba:

> On Jul 17, 2016, at 22:56, Gunnar Hellström 
> <[email-masked] <mailto:[email-masked]>> wrote:
>> These use cases both result in a need to specify sending and 
>> receiving in English in both audio and text media.
> [BA] The current draft enables the language capabilities for each 
> media to be expressed and negotiated in each direction. This enables 
> media preference to be expressed and implemented subsequently (either 
> through conversation or by a yet unspecified mechanism).
I assume that you mean language preference, because there may be more 
than one language per media and there may be more than one media 
carrying language indications. And we have said that non-matching 
language indications should not be taken as a reason to not connect a 
medium.
> [BA] It means that the capability to use those languages 
> bidirectionally has been negotiated - no usage obligation.
OK, I have a presentation for the meeting where some wording is proposed 
to document that.
How about having usage obligation for the languages in the answer? Or at 
least for the ones with "-send" in the answer.

We should also add the sentence that is now added to the lang attribute 
in rfc4566bis:
"

    Events during the session can influence which language(s) are used,
    and the participants are not strictly bound to only use the declared
    languages.
"

>> Looking forward to the meeting and progress in Slim.
I touch two other topics in the presentation that can be good to start 
thinking about:

a) Is the notation for advisory vs required with an asterisk for 
advisory really wanted? I do not think it is ever wanted to 
automatically deny a call because no languages match. There may be close 
to matching cases. Better to show the info to the user.
If the asterisk is deleted, then that notation could be used for 
something else.

b) How to make the notation usable with media that are "hidden" in 
transports not using the main MIME type hinting on the modality, e.g. 
the text medium that in WebRTC will be multiplexed in a subchannel of 
the data channel declared as "application" type. We may need to register 
a "modality" attribute as well to mark the subchannel with, and use that 
in  a dsca attribute as specified in sdpneg.

/Gunnar

>>>>  A simple mechanism to tell when the most desirable outcome is to 
>>>> be provided with two languages/modalities together rather than the 
>>>> decisions on media session establishment, but rather for 
>>>>  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.
>>>>
>>>>>  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 
>>>>>>  This includes providing guidance to the answering part so that 
>>>>>> the answer can be made in the most appropriate language(s).
>>>>>>
>>>>>>  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.
>>>>>>
>>>>>> these modalities. If not, the call will start with confusion 
>>>>>> about what is the most efficient means for them to communicate.
>>>>>>
>> [email-masked] <mailto:[email-masked]>