Subject: [Slim] [slim] #8 (negotiating-human-language): Introduce a section on most favoured modality

From: "slim issue tracker" <[email-masked]>
Date: Tue, 09 Aug 2016 07:03:35 -0000

#8: Introduce a section on most favoured modality

 In order to have an opportunity to start the call in the most suitable
 modality, an indication of most favoured modality is needed together with
 the language indications. Introduce a new section on that topic. Without
 this, the answering part is left without a clue about how to start the
 call.

 Text for new section in chapter 6
 -----------------------------------------------------------------

 6.y Most favoured modality
 In order to successfully start a call, the parties need to be aware of
 which language capabilities were negotiated, and also which modality the
 parties prefer to use. A call can start without hesitation and be
 conducted smoothly only when answered with the modality and language that
 best matches the most favoured combinations by the caller. There is a
 tendency among call participants to continue using the modality first used
 in a call, even if that is not the most favoured modality. The call
 participants usually want to communicate about the topic of the call, and
 not about how the call will be performed. Therefore, a mechanism is
 provided for indication of most preferred modality/modalities of the call
 participants together with the language attributes.

 The mechanism provides a "favoured" modality parameter that MAY be
 included in the "humintlang-send" and "humintlang-recv" attribute values
 on media level. The "favoured" modality parameter is a keyword parameter
 with the name "favoured" and values "most" and "complement".
 This parameter is intended to be optionally included once for each
 combination of media, modality and direction of language. The indication
 is intended to carry the information that that combination is the highest
 favoured alternative if the value is "most", and is a highly favoured
 complement to the most favoured modality in another media description if
 the value is "complement". The value "most" is allowed for more than one
 media/modality/direction combination for cases when it is essential for
 the indicating party to use more than one modality in the same direction.
 The "complement" value SHOULD not be used without any "most" value in the
 sdp, and should only be used for cases when the modality it is used with
 is supposed to be used for language transfer simultanously with the
 corresponding most favoured modality.

-- 
-------------------------------------+-------------------------------------
 Reporter:                           |      Owner:  draft-ietf-slim-
  [email-masked]        |  [email-masked]
     Type:  enhancement              |     Status:  new
 Priority:  major                    |  Milestone:
Component:  negotiating-human-       |    Version:
  language                           |   Keywords:  modality
 Severity:  In WG Last Call          |
-------------------------------------+-------------------------------------

Ticket URL: <https://trac.tools.ietf.org/wg/slim/trac/ticket/8>
slim <https://tools.ietf.org/slim/>

---

From: Brian Rosen <[email-masked]>
Date: Tue, 9 Aug 2016 09:02:19 -0400

I don’t think this is a good idea.

Brian
> On Aug 9, 2016, at 3:03 AM, slim issue tracker <[email-masked]> wrote:
> 
> _______________________________________________
> SLIM mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/slim

---

From: "slim issue tracker" <[email-masked]>
Date: Mon, 15 Aug 2016 16:56:58 -0000

Comment (by [email-masked]):

 Chairs: This topic has been discussed at length in WG meetings and on-
 list. The decision was not to include this within this document, but it
 could be in scope for another piece of work.

  language                           |  Resolution:
 Keywords:  modality                 |

Ticket URL: <https://trac.tools.ietf.org/wg/slim/trac/ticket/8#comment:1>
slim <https://tools.ietf.org/slim/>

---

From: "slim issue tracker" <[email-masked]>
Date: Mon, 15 Aug 2016 16:57:25 -0000

Changes (by [email-masked]):

 * status:  new => closed
 * resolution:   => wontfix

-- 
-------------------------------------+-------------------------------------
 Reporter:                           |       Owner:  draft-ietf-slim-
  [email-masked]        |  [email-masked]
     Type:  enhancement              |      Status:  closed
 Priority:  major                    |   Milestone:
Component:  negotiating-human-       |     Version:
  language                           |  Resolution:  wontfix
 Severity:  In WG Last Call          |
 Keywords:  modality                 |
-------------------------------------+-------------------------------------

Ticket URL: <https://trac.tools.ietf.org/wg/slim/trac/ticket/8#comment:2>
slim <https://tools.ietf.org/slim/>

---

From: "slim issue tracker" <[email-masked]>
Date: Tue, 16 Aug 2016 21:36:26 -0000

Comment (by [email-masked]):

 This is not anymore a fully specified preference level between languages
 in different modalities. In this version it is just a single indication of
 the most favoured modality ( and by that the most favoured language).

 It is such a small addition, and so urgently needed to make the draft
 useful, that it should be allowed to be included.

Ticket URL: <https://trac.tools.ietf.org/wg/slim/trac/ticket/8#comment:3>
slim <https://tools.ietf.org/slim/>

---

From: Brian Rosen <[email-masked]>
Date: Tue, 16 Aug 2016 17:50:28 -0400

I don’t think this is useful, and I think it’s beyond the consensus on what this document would contain.

If I send an offer of English audio and you can do it, then you will send an answer with English audio.  If you can’t do it, then your answer won’t include English audio.  Me telling you that English audio is most important doesn’t change your answer.  This is especially true with modality.  There is no way I can use advice of which modality is most important to you.  If you offer video, I answer with some video if I can do video.  If I can’t I won’t include a video answer.  Telling me you realty, really want video isn’t useful.

Please remember, we’re not designing user interfaces, we’re designing protocols.

Brian

> On Aug 16, 2016, at 5:36 PM, slim issue tracker <[email-masked]> wrote:
>

---

From: Gunnar Hellström <[email-masked]>
Date: Wed, 17 Aug 2016 15:22:14 +0200

> If I send an offer of English audio and you can do it, then you will send an answer with English audio.  If you can’t do it, then your answer won’t include English audio.  Me telling you that Engli…
In some limited examples that would lead to successful call start.
But consider a couple of other simple cases:
A. Two common spoken languages:
I send an offer of spoken English and French in audio in both 
directions, and you have configured your device that you also know 
English and French in both directions.
Then, the protocol selects spoken English and puts that in the answer. 
In order for the call to complete successfully you then need to know 
that English both ways was selected, so that you start talking English 
in your answer. It would be a failure of our intentions if you only got 
a connected indication and needed to start asking me what language I 
prefer.
We do not specify how the information is conveyed to you, but it is.
Even if you knew French and Italian, you would need to know that the 
common language is French.

B.  One spoken and one written language
I send an offer with spoken English in audio and written English in 
text. I call you, and you have also configured spoken English in audio 
and written English in text.
We both prefer to talk if we have a chance.
The negotiation succeeds and you get an indication that audio and text 
are the available media. If you do not get any preference indication, 
you do not know how to start the call. You may try English text fist and 
type "Hi, welcome, what can I do for you". I notice that you type, so I 
answer in text, because I do not know if you can talk English. We might 
continue the whole call in text, or take the effort to ask if we can 
change to talking.
Not until you get to know that we both can use spoken English and that 
it is the preferred match, you get a chance to respond in spoken English 
and the call starts well. The device can convey the negotiation result 
to you without us specifyinng how, but we need to describe that my 
preference for spoken modality is conveyed by the protocol.

Many other examples can easily be constructed where we both need the 
preference between modalities and that the user get to know the result 
of the negotiation, or at least the best matching languages.

> Please remember, we’re not designing user interfaces, we’re designing protocols.
Yes, we specify the protocol for conveying information about language 
and modality between the sides involved in the call.
In most cases some mechanism that we do not describe needs to take this 
information to the user so that the call can be completed successfully.
The other way - that the user is expected to configure the languages and 
modalities is briefly mentioned in the introduction by these words:

"Since this is a protocol mechanism, the user equipment (UE client)

    needs to know the user's preferred languages; a reasonable technique
    could include a configuration mechanism with a default of the language of the user interface."

I suggest that we also say that "The result of the negotiation is expected to be provided to the user in most applications of this mechanism,
but it is out of scope to specify how this is done."

That would not be specifying user interface but clarifying the main purpose.

The paragraph in the introduction continues:

    "In some cases, a UE could tie
    language and media preferences, such as a preference for a video
    stream using a signed language and/or a text or audio stream using a
    written/spoken language."

I take this sentence as a promise that later in the document we will read how such preference between languages in different modalities
is coded and conveyed between the UEs. Our work is not complete and does not do its job until we have specified a mechanism for that.

It can be sufficient to add indication of the most preferred modality to the protocol, because within the modalities we have the order of the attributes as the preference order.

Gunnar

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

---

From: Brian Rosen <[email-masked]>
Date: Wed, 17 Aug 2016 09:35:07 -0400

> On Aug 17, 2016, at 9:22 AM, Gunnar Hellström <[email-masked]> wrote:
> 
> I send an offer of spoken English and French in audio in both directions, and you have configured your device that you also know English and French in both directions. 
> Then, the protocol selects spoken English and puts that in the answer. In order for the call to complete successfully you then need to know that English both ways was selected, so that you start talking English in your answer. It would be a failure of our intentions if you only got a connected indication and needed to start asking me what language I prefer. 
The protocol answer was English.  Both ends know that.  User interface is out of scope.

> Even if you knew French and Italian, you would need to know that the common language is French.
> 
> I send an offer with spoken English in audio and written English in text. I call you, and you have also configured spoken English in audio and written English in text. 
> The negotiation succeeds and you get an indication that audio and text are the available media. If you do not get any preference indication, you do not know how to start the call. You may try English text fist and type "Hi, welcome, what can I do for you". I notice that you type, so I answer in text, because I do not know if you can talk English. We might continue the whole call in text, or take the effort to ask if we can change to talking. 
> Not until you get to know that we both can use spoken English and that it is the preferred match, you get a chance to respond in spoken English and the call starts well. The device can convey the negotiation result to you without us specifyinng how, but we need to describe that my preference for spoken modality is conveyed by the protocol.
The protocol exchange informs BOTH ENDS that both voice and text is negotiated.  It’s perfectly fine for either end to start in either modality, and switch any time they want to.

> 
>   
> Many other examples can easily be constructed where we both need the preference between modalities and that the user get to know the result of the negotiation, or at least the best matching languages.
>     
> Yes, we specify the protocol for conveying information about language and modality between the sides involved in the call. 
> In most cases some mechanism that we do not describe needs to take this information to the user so that the call can be completed successfully. 
> The other way - that the user is expected to configure the languages and modalities is briefly mentioned in the introduction by these words:
> 
>    could include a configuration mechanism with a default of the language of the user interface.”
That’s in scope, because it’s discussing configuration for the protocol exchange.
> but it is out of scope to specify how this is done.”
That’s out of scope, that’s strictly user interface

> is coded and conveyed between the UEs. Our work is not complete and does not do its job until we have specified a mechanism for that. 
We can edit this text to remove the inference.

>>> On Aug 16, 2016, at 5:36 PM, slim issue tracker <[email-masked]> <mailto:[email-masked]> wrote:
>>> 
>>> Comment (by [email-masked] <mailto:[email-masked]>):
>>> 
>>>  [email-masked] <mailto:[email-masked]>        |  [email-masked] <mailto:[email-masked]>
>>> Ticket URL: <https://trac.tools.ietf.org/wg/slim/trac/ticket/8#comment:3> <https://trac.tools.ietf.org/wg/slim/trac/ticket/8#comment:3>
>>> slim <https://tools.ietf.org/slim/> <https://tools.ietf.org/slim/>
>>> 
>>> [email-masked] <mailto:[email-masked]>
>>> https://www.ietf.org/mailman/listinfo/slim <https://www.ietf.org/mailman/listinfo/slim>
> 
> -- 
> [email-masked] <mailto:[email-masked]>
> +46 708 204 288

---

From: Gunnar Hellström <[email-masked]>
Date: Wed, 17 Aug 2016 16:13:04 +0200

Den 2016-08-17 kl. 15:35, skrev Brian Rosen:
>
>> On Aug 17, 2016, at 9:22 AM, Gunnar Hellström 
>> <[email-masked] <mailto:[email-masked]>> wrote:
>>
>> Then, the protocol selects spoken English and puts that in the 
>> answer. In order for the call to complete successfully you then need 
>> to know that English both ways was selected, so that you start 
>> talking English in your answer. It would be a failure of our 
>> intentions if you only got a connected indication and needed to start 
>> asking me what language I prefer.
Yes, user interface mechanisms are out of scope, but the intention of 
our work is not completed if the called user does not know the result of 
the negotiation ( in most cases ). So for this example we have the 
preference indication we need, and we can say that the user needs to 
know the result but the mechanism for that is out of scope.
>> text. I call you, and you have also configured spoken English in 
>> audio and written English in text.
>> The negotiation succeeds and you get an indication that audio and 
>> text are the available media. If you do not get any preference 
>> indication, you do not know how to start the call. You may try 
>> English text fist and type "Hi, welcome, what can I do for you". I 
>> notice that you type, so I answer in text, because I do not know if 
>> you can talk English. We might continue the whole call in text, or 
>> take the effort to ask if we can change to talking.
>> Not until you get to know that we both can use spoken English and 
>> that it is the preferred match, you get a chance to respond in spoken 
>> English and the call starts well. The device can convey the 
>> negotiation result to you without us specifyinng how, but we need to 
>> describe that my preference for spoken modality is conveyed by the 
>> protocol.
> The protocol exchange informs BOTH ENDS that both voice and text is 
> negotiated.  It’s perfectly fine for either end to start in either 
> modality, and switch any time they want to.
No that is not perfectly fine. It is inconvenient and awkward to 
communicate in other than your favoured modality. And it is awkward to 
have a dialogue about what alternatives there are. A most simple 
mechanism to configure and convey the modality preference is needed as 
part of our protocol.

You can have even more examples where the solution is to both have a 
favoured modality indication and a way (not specified by us) to convey 
the result of the negotiation to the users.

Why shall we make a difference in conveying preference between languages 
in the same modality but not in different modalities? I do not see the 
logic in that.

/Gunnar

>> preference between modalities and that the user get to know the 
>> result of the negotiation, or at least the best matching languages.
>>
>> In most cases some mechanism that we do not describe needs to take 
>> this information to the user so that the call can be completed 
>> successfully.
>> The other way - that the user is expected to configure the languages 
>> and modalities is briefly mentioned in the introduction by these words:
>>
Well, let us add favoured modality and we are done.
> That’s out of scope, that’s strictly user interface.
Can you propose a rewording that it matches your view.
> We can edit this text to remove the inference.
We need instead sharpen it and then explain how.

/Gunnar
>>>> On Aug 16, 2016, at 5:36 PM, slim issue tracker<[email-masked]>  wrote:
>>>>
>>>> Comment ([email-masked]):
>>>>
>>>>   [email-masked]         [email-masked]
>>>> Ticket URL:<https://trac.tools.ietf.org/wg/slim/trac/ticket/8#comment:3>
>>>> slim<https://tools.ietf.org/slim/>
>>>>

---

From: Brian Rosen <[email-masked]>
Date: Wed, 17 Aug 2016 10:25:46 -0400

When you walk up to someone, and you both know more than one language, how do you start? 

We’re actually very good at figuring out that kind of thing and we don’t need a lot of help to do it.

I’m not at all worried about humans figuring out what to do as long as we get calls to people who actually can understand the languages the caller prefers.

I’m very, very suspicious of things that make assumptions about user interface.  You are making lots of assumptions.  One of them is that there is a human answering the call.  That is NOT something we should assume.  Automatons behave differently than humans.  That’s sometimes bad, but it’s sometimes good.

I’m also against being a specification nanny.  Just as there are no protocol police, there are no user interface police, and it may NOT be the right thing to tell a user what the other guy’s modality choice is.  

Brian

> On Aug 17, 2016, at 10:13 AM, Gunnar Hellström <[email-masked]> wrote:
> 
> 
> 
>>> On Aug 17, 2016, at 9:22 AM, Gunnar Hellström <[email-masked] <mailto:[email-masked]>> wrote:
>>> 
> Yes, user interface mechanisms are out of scope, but the intention of our work is not completed if the called user does not know the result of the negotiation ( in most cases ). So for this example we have the preference indication we need, and we can say that the user needs to know the result but the mechanism for that is out of scope.
>> 
> No that is not perfectly fine. It is inconvenient and awkward to communicate in other than your favoured modality. And it is awkward to have a dialogue about what alternatives there are. A most simple mechanism to configure and convey the modality preference is needed as part of our protocol.  
> 
> You can have even more examples where the solution is to both have a favoured modality indication and a way (not specified by us) to convey the result of the negotiation to the users.
> 
> Why shall we make a difference in conveying preference between languages in the same modality but not in different modalities? I do not see the logic in that.
> 
> /Gunnar
> 
>  
>> 
>>> 
>>>

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 17 Aug 2016 11:03:44 -0400

In general I think I agree with you. But I want to ensure we are getting 
to a place where we will be able to dispense with the "Press 1 if you 
speak Spanish".

When I call a call center I want to be directed automatically to someone 
who speaks my language and then be greeted in a language I speak.

	Thanks,
	Paul

On 8/17/16 10:25 AM, Brian Rosen wrote:
> I’m not at all worried about humans figuring out what to do as long as
> we get calls to people who actually can understand the languages the
> caller prefers.
>
> I’m very, very suspicious of things that make assumptions about user
> interface.  You are making lots of assumptions.  One of them is that
> there is a human answering the call.  That is NOT something we should
> assume.  Automatons behave differently than humans.  That’s sometimes
> bad, but it’s sometimes good.
>
> I’m also against being a specification nanny.  Just as there are no
> protocol police, there are no user interface police, and it may NOT be
> the right thing to tell a user what the other guy’s modality choice is.
>
> Brian
>
>
>> On Aug 17, 2016, at 10:13 AM, Gunnar Hellström
>>>> intentions if you only got a connected indication and needed to
>>>> start asking me what language I prefer.
>> our work is not completed if the called user does not know the result
>> of the negotiation ( in most cases ). So for this example we have the
>>>> that it is the preferred match, you get a chance to respond in
>>>> spoken English and the call starts well. The device can convey the
>> Why shall we make a difference in conveying preference between
>> languages in the same modality but not in different modalities? I do
>> not see the logic in that.
>>
>> /Gunnar
>>
>>
>>>
>>>>
>>>>
>>>> Yes, we specify the protocol for conveying information about
>>>> language and modality between the sides involved in the call.

---

From: Brian Rosen <[email-masked]>
Date: Wed, 17 Aug 2016 13:36:25 -0400

Absolutely, that’s one of my goals.  You indicate your preference for Spanish, and we route your call to a Spanish speaker.  We know we’ve negotiated Spanish, so if the call taker is bilingual, the UI could show them what was negotiated.  Furthermore, if we need to send the call to an IVR, the IVR knows what was negotiated and thus plays the right prompts, which is an example where there is  no UI (on the call answering side).

Brian

> On Aug 17, 2016, at 11:03 AM, Paul Kyzivat <[email-masked]> wrote:
> 
> In general I think I agree with you. But I want to ensure we are getting to a place where we will be able to dispense with the "Press 1 if you speak Spanish".
> 
> When I call a call center I want to be directed automatically to someone who speaks my language and then be greeted in a language I speak.
> 
> 	Thanks,
> 	Paul
> 
>>> <[email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>> wrote:
>>> 
>>> 
>>> 
>>>>> <[email-masked] <mailto:[email-masked]> <mailto:[email-masked] <mailto:[email-masked]>>>
>>>>> wrote:
>>>>> 
>>>>>>> On Aug 16, 2016, at 5:36 PM, slim issue tracker <[email-masked] <mailto:[email-masked]>> wrote:
>>>>>>>

---

From: Randall Gellens <[email-masked]>
Date: Wed, 17 Aug 2016 21:28:39 -0700

At 3:22 PM +0200 8/17/16, Gunnar Hellström wrote:

>   In order for the call to complete successfully 
> you then need to know that English both ways 
> was selected, so that you start talking English 
> in your answer. It would be a failure of our 
> intentions if you only got a connected 
> indication and needed to start asking me what 
> language I prefer.

Both endpoints know what was set up (English 
audio in your example).  What the endpoints do 
with this knowledge, including if and how they 
communicate it to the user, is out of scope.

-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly selected tag: ---------------
How does a project get to be a year behind schedule?
One day at a time.   --Fred Brooks in _The Mythical Man Month_

---

From: Gunnar Hellström <[email-masked]>
Date: Thu, 18 Aug 2016 08:26:47 +0200

Den 2016-08-18 kl. 06:28, skrev Randall Gellens:
>>   In order for the call to complete successfully you then need to 
>> know that English both ways was selected, so that you start talking 
>> English in your answer. It would be a failure of our intentions if 
>> you only got a connected indication and needed to start asking me 
>> what language I prefer.
>
> Both endpoints know what was set up (English audio in your example).  
> What the endpoints do with this knowledge, including if and how they 
Yes, agreed. So our task in this draft is to describe the mechanism that 
enable the endpoints to have the information needed for a successful and 
smooth start of the call = greeting from the called party in the most 
appropriate language and modality.

Gunnar

---

From: Martin J. Dürst <[email-masked]>
Date: Thu, 18 Aug 2016 20:45:00 +0900

> the result of the negotiation to the users.

I'm only trying to extrapolate from my own personal use of current 
(possibly non-standardized) technology like chats and skype and the like.

My observation would be the following:

Language abilities and therefore preferences are more or less fixed 
[There is the case that I'm more familiar to talk about technical 
subjects in English while I'd be more at ease in another language for 
some other topics, but that's definitely something very advanced.]

On the other hand, modality preferences often change very quickly. I may 
wait for a train and be comfortable with voice on the platform, but as 
soon as I board the train, I might prefer to change to text to not annoy 
other passengers (in some places, there's very strong social pressure to 
avoid talking in a train). I might start with something that I think can 
be dealt with in text, to later realize that I need speech to get my 
ideas across. More such situations are easy to come up with, also for video.

So in order to be able to indicate a preferred modality, the system 
might have to check with me continuously, and I might have to update my 
preference very often, or get them wrong lots of time. That to me sounds 
like an argument for not standardizing "favorite modality".

Regards,   Martin.

---

From: Randall Gellens <[email-masked]>
Date: Thu, 18 Aug 2016 09:54:21 -0700

At 8:26 AM +0200 8/18/16, Gunnar Hellström wrote:

>>>    In order for the call to complete 
>>> successfully you then need to know that 
>>> English both ways was selected, so that you 
>>> start talking English in your answer. It 
>>> would be a failure of our intentions if you 
>>> only got a connected indication and needed to 
>  Yes, agreed. So our task in this draft is to 
> describe the mechanism that enable the 
> endpoints to have the information needed for a 
> successful and smooth start of the call = 
> greeting from the called party in the most 

No, the task is to enable the endpoints to set up 
the media.  What they do then is up to them.  You 
might want to write an "advice to implementers" 
draft that provides information and suggestions 
to implementers as to how to have a successful 
call.  But that needs to be an entirely separate 
and purely informational draft.  In lieu of an 
IETF draft, you could instead publish the 
information as a blog post or web page.

-------------- Randomly selected tag: ---------------
The very first "flight attendants" were three 14-year old cabin boys,
who were hired by Great Britain's Daimler Airways in 1922. Passenger
service, rather than safety, was the primary reason these "airborne
bellboys" were included on the flight. Food and beverage service was
not offered on these first flights. Apparently, the reason for these
boys to be in the cabin was more for aesthetics rather than
functionality.
    --airlinesafety.com/editorials/CockpitCabinPsychology.htm

---

From: Bernard Aboba <[email-masked]>
Date: Thu, 18 Aug 2016 10:15:40 -0700

Martin said:

"So in order to be able to indicate a preferred modality, the system might
have to check with me continuously..."

[BA]  Good point. To deal with conditions that can change rapidly, it is
best to avoid signaling if possible, particularly where congestion could be
involved.

 A caller might "prefer" to sign, but discovers that the webcam is not
functioning or connectivity is poor so they switch to using text.  Perhaps
the issue with video clears up, so now they can switch to signing. In these
situations, it could be a burden to signal a change in "preferred modality"
(or even to renegotiate the media), particularly if congestion is severe
enough to cause delays in signaling or even signaling failure. It might be
more convenient to handle these temporary conditions by "muting" or
"unmuting" media, or changing aspects of the media encoding (e.g. lowering
resolution or dropping spatial layers but maintaining framerate to protect
the viability of signing), rather than signaling. This is why we have an
RTCP message (PAUSED) or a codec-specific message (SEI layer drop) to
indicate that a peer is dropping a stream or layer, which makes it possible
to avoid signaling this in SDP.

On Thu, Aug 18, 2016 at 4:45 AM, Martin J. Dürst <[email-masked]>
wrote:

> Language abilities and therefore preferences are more or less fixed [There
> is the case that I'm more familiar to talk about technical subjects in
> English while I'd be more at ease in another language for some other
> topics, but that's definitely something very advanced.]
>
> wait for a train and be comfortable with voice on the platform, but as soon
> as I board the train, I might prefer to change to text to not annoy other
> passengers (in some places, there's very strong social pressure to avoid
> talking in a train). I might start with something that I think can be dealt
> with in text, to later realize that I need speech to get my ideas across.
> More such situations are easy to come up with, also for video.
>
> So in order to be able to indicate a preferred modality, the system might
> have to check with me continuously, and I might have to update my

---

From: Gunnar Hellström <[email-masked]>
Date: Thu, 18 Aug 2016 22:11:34 +0200

Den 2016-08-18 kl. 19:15, skrev Bernard Aboba:

> Martin said:
>
> "So in order to be able to indicate a preferred modality, the system 
> might have to check with me continuously..."
>
> [BA]  Good point. To deal with conditions that can change rapidly, it 
> is best to avoid signaling if possible, particularly where congestion 
> could be involved.
Yes, such situations may occur, and various solutions can be made to 
handle such cases smoothly. One simple solution is of course that for 
the cases when you select to make a text call without video, then your 
setting for sign language as the preferred modality is not included 
because it would have been included with the m=video media description.
There are other solutions on the same situation where you still have 
benefit of the modality preference indication to make the calling more 
convenient than it is today.
And you may of course also select to not do any modality preference 
setting and get answered in a random modality.

On the other hand, there are many users with quite stable conditions who 
want the convenience of the requirement that Paul stated:
"When I call a call center I want to be directed automatically to 
someone who speaks my language and then be greeted in a language I speak."

If the Dutch and French relay services still are as I latest saw them 
working, they start the call with asking the user if sign language or 
real-time text relaying is wanted, and the user needs to enter a simple 
text response before getting connected. It is a possible mechanism 
today, but our draft should offer a possibility to automate that mechanism.

So, we shall not avoid standardizing a good function just because there 
are cases when you can do reasonably without it.

/Gunnar

> functioning or connectivity is poor so they switch to using text.  
> Perhaps the issue with video clears up, so now they can switch to 
> signing. In these situations, it could be a burden to signal a change 
> in "preferred modality" (or even to renegotiate the media), 
> particularly if congestion is severe enough to cause delays in 
> signaling or even signaling failure. It might be more convenient to 
> handle these temporary conditions by "muting" or "unmuting" media, or 
> changing aspects of the media encoding (e.g. lowering resolution or 
> dropping spatial layers but maintaining framerate to protect the 
> viability of signing), rather than signaling. This is why we have an 
> indicate that a peer is dropping a stream or layer, which makes it 
> possible to avoid signaling this in SDP.
>
> On Thu, Aug 18, 2016 at 4:45 AM, Martin J. Dürst 
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>
>
>                 <[email-masked]
>                 <mailto:[email-masked]>
>                 <mailto:[email-masked]
>                 <mailto:[email-masked]>>>
>                 wrote:
>
>     Language abilities and therefore preferences are more or less
>     fixed [There is the case that I'm more familiar to talk about
>     technical subjects in English while I'd be more at ease in another
>     language for some other topics, but that's definitely something
>     very advanced.]
>
>     On the other hand, modality preferences often change very quickly.
>     I may wait for a train and be comfortable with voice on the
>     platform, but as soon as I board the train, I might prefer to
>     change to text to not annoy other passengers (in some places,
>     there's very strong social pressure to avoid talking in a train).
>     I might start with something that I think can be dealt with in
>     text, to later realize that I need speech to get my ideas across.
>     So in order to be able to indicate a preferred modality, the
>     system might have to check with me continuously, and I might have
>     to update my preference very often, or get them wrong lots of
>     time. That to me sounds like an argument for not standardizing
>     "favorite modality".
>
>     Regards,   Martin.
>
>
>     <https://www.ietf.org/mailman/listinfo/slim>
>
>

---

From: Gunnar Hellström <[email-masked]>
Date: Thu, 18 Aug 2016 22:30:29 +0200

Den 2016-08-18 kl. 18:54, skrev Randall Gellens:

>>>  Both endpoints know what was set up (English audio in your 
>>> example).  What the endpoints do with this knowledge, including if 
>>> and how they communicate it to the user, is out of scope.
>>>
>>  Yes, agreed. So our task in this draft is to describe the mechanism 
>> that enable the endpoints to have the information needed for a 
>> successful and smooth start of the call = greeting from the called 
>> party in the most appropriate language and modality.
>
> No, the task is to enable the endpoints to set up the media.
This is not about setting up media. It is about conveying info to the 
endpoints about what language to fill the media connections with. We 
have said many times that media included in the offer are wanted anyway 
even if they are not used for language.
The role for what we do for language is similar to what RFC 4796 The SDP 
Contents Attribute does for content types. It provides additional 
information about the media to both endpoints.
In our case the information provided shall be sufficient for starting 
the call in an appropriate language and modality. We do not say how the 
result of the negotiation is provided to the "language generating 
entity", we just convey it to the endpoint ( or terminal or UA or 
client, whatever we want to call it ) but the information needs to be 
sufficient to give most cases proper base for the decision.
>   What they do then is up to them.  You might want to write an "advice 
> to implementers" draft that provides information and suggestions to 
> implementers as to how to have a successful call.  But that needs to 
> be an entirely separate and purely informational draft.  In lieu of an 
> IETF draft, you could instead publish the information as a blog post 
> or web page.
Yes, why is this repeated so many times?
Let us instead complete the task to decide on information and syntax to 
convey between the endpoints.

/Gunnar

---

From: Gunnar Hellström <[email-masked]>
Date: Fri, 19 Aug 2016 09:18:52 +0200

It is amazing that we have not yet been able to solve the need for 
preference indication independent of media.

We have been discussing it for 40 months (!), the surrounding standards 
requiring it have defined that they need the function but cannot go on 
to detail stage 3 of how to use our specification for this need.

With the current draft I can specify that I prefer to speak English but 
can also with lower preference accept to speak French.

But I cannot specify that I prefer to sign BSL (British Sign Language) 
but can also with lower preference accept to read and write English. I 
do not see any logic in making that difference. It is just an incomplete 
specification. And, since the examples about routing and setting up 
calls are preferred in this discussion, I can take a simple example from 
when this indication is useful:

We have directives in force in Europe saying that all shall be equally 
well taken care of by emergency services.

1. Person A prefers to use written English but knows BSL. (BSL is 
included in the capability indication so that calls with friends can be 
held in BSL without any relay service coming into the call)

2. Person B prefers BSL but can accept to use written English. (Written 
English is included in the capability indication so that calls with 
hearing people with text capability can be held in text without a relay 
service coming into the call )

3. An emergency service has a small group of people who communicate well 
in BSL and other call-takers who speak and type English.

4. When user B calls emergency service, the call should be routed to the 
small group knowing sign language well and the call should start in BSL.

5. When user A calls emergency service, the call should be routed to the 
general call-takers who have text and spoken capabilities.

6. With a method for preference indication between written English and 
BSL, the ESInet can do the routing and send each call to the group most 
suited to take it.

7. Without a method for distinguishing the priorities between the two 
users, there is no way to route the calls to appropriate call-takers.

Many other similar examples can be made, from emergency calling as well 
as everyday calling.
So let us solve this need in the draft. I have proposed about 4 
notations, with gradually reduced functionality, but still capable of 
solving the most apparent needs. They are depending on what syntax we 
take for the attributes, so let us try to decide on both the attribute 
syntax and the most favoured modality indication syntax together.

/Gunnar

Den 2016-08-18 kl. 22:30, skrev Gunnar Hellström:
>>>>> know that English both ways was selected, so that you start 
> have said many times that media included in the offer are wanted 
> anyway even if they are not used for language.
> The role for what we do for language is similar to what RFC 4796 The 
> SDP Contents Attribute does for content types. It provides additional 
> the call in an appropriate language and modality. We do not say how 
> the result of the negotiation is provided to the "language generating 
>>   What they do then is up to them.  You might want to write an 
>> "advice to implementers" draft that provides information and 
>> suggestions to implementers as to how to have a successful call.  But 
>> that needs to be an entirely separate and purely informational 
>> draft.  In lieu of an IETF draft, you could instead publish the 
> Let us instead complete the task to decide on information and syntax 
> to convey between the endpoints.
>
> /Gunnar
>>
>>
>

---

From: Brian Rosen <[email-masked]>
Date: Fri, 19 Aug 2016 09:38:51 -0400

You differentiate by setting English video with higher priority than BSL video for A, while only sending BSL video for B.  You send english text for both.  You probably send English audio for A.  The right thing happens.

You have never provided a believable example that requires what you are asking for.  Every example has a reasonable solution that doesn’t need any more mechanism.  I’ll agree there are some examples where it may make the situation somewhat more optimal, but the result without any more mechanism is fine, human’s being as adaptable as they are.

We’re trying to keep the mechanism simple by treating each m line independent of other m lines.  It’s a reasonable position to take.  

I did think about suggesting that BSL audio for an emergency call is an interesting request.  It means “I’m deaf, but I have an audio channel, so if you wanted to hear my background audio, go ahead and set it up, but don’t expect to be able to speak to me”.

Brian

> On Aug 19, 2016, at 3:18 AM, Gunnar Hellström <[email-masked]> wrote:
> 
> It is amazing that we have not yet been able to solve the need for preference indication independent of media.
> 
> We have been discussing it for 40 months (!), the surrounding standards requiring it have defined that they need the function but cannot go on to detail stage 3 of how to use our specification for this need.
> 
> With the current draft I can specify that I prefer to speak English but can also with lower preference accept to speak French.
> 
> But I cannot specify that I prefer to sign BSL (British Sign Language) but can also with lower preference accept to read and write English. I do not see any logic in making that difference. It is just an incomplete specification. And, since the examples about routing and setting up calls are preferred in this discussion, I can take a simple example from when this indication is useful:
> 
> We have directives in force in Europe saying that all shall be equally well taken care of by emergency services.
> 
> 1. Person A prefers to use written English but knows BSL. (BSL is included in the capability indication so that calls with friends can be held in BSL without any relay service coming into the call)
> 
> 2. Person B prefers BSL but can accept to use written English. (Written English is included in the capability indication so that calls with hearing people with text capability can be held in text without a relay service coming into the call )
> 
> 3. An emergency service has a small group of people who communicate well in BSL and other call-takers who speak and type English.
> 
> 4. When user B calls emergency service, the call should be routed to the small group knowing sign language well and the call should start in BSL.
> 
> 5. When user A calls emergency service, the call should be routed to the general call-takers who have text and spoken capabilities.
> 
> 6. With a method for preference indication between written English and BSL, the ESInet can do the routing and send each call to the group most suited to take it.
> 
> 7. Without a method for distinguishing the priorities between the two users, there is no way to route the calls to appropriate call-takers.
> 
> Many other similar examples can be made, from emergency calling as well as everyday calling.
> So let us solve this need in the draft. I have proposed about 4 notations, with gradually reduced functionality, but still capable of solving the most apparent needs. They are depending on what syntax we take for the attributes, so let us try to decide on both the attribute syntax and the most favoured modality indication syntax together.
> 
> /Gunnar
> 
> 
>>>>>>   In order for the call to complete successfully you then need to know that English both ways was selected, so that you start talking English in your answer. It would be a failure of our intentions if you only got a connected indication and needed to start asking me what language I prefer.
>>>>> 
>>>>> Both endpoints know what was set up (English audio in your example).  What the endpoints do with this knowledge, including if and how they communicate it to the user, is out of scope.
>>>>> 
>>>> Yes, agreed. So our task in this draft is to describe the mechanism that enable the endpoints to have the information needed for a successful and smooth start of the call = greeting from the called party in the most appropriate language and modality.
>>> 
>> This is not about setting up media. It is about conveying info to the endpoints about what language to fill the media connections with. We have said many times that media included in the offer are wanted anyway even if they are not used for language.
>> The role for what we do for language is similar to what RFC 4796 The SDP Contents Attribute does for content types. It provides additional information about the media to both endpoints.
>> In our case the information provided shall be sufficient for starting the call in an appropriate language and modality. We do not say how the result of the negotiation is provided to the "language generating entity", we just convey it to the endpoint ( or terminal or UA or client, whatever we want to call it ) but the information needs to be sufficient to give most cases proper base for the decision.
>>>  What they do then is up to them.  You might want to write an "advice to implementers" draft that provides information and suggestions to implementers as to how to have a successful call.  But that needs to be an entirely separate and purely informational draft.  In lieu of an IETF draft, you could instead publish the information as a blog post or web page.
>> Let us instead complete the task to decide on information and syntax to convey between the endpoints.
>> 
>> /Gunnar
>>> 
>>> 
>> 
> 
> --

---

From: Natasha Rooney <[email-masked]>
Date: Fri, 19 Aug 2016 15:27:40 +0000

Hi all,

The chairs (myself and Bernard) have discussed this item and I wish to reiterate the same point we have made at many stages:

This work is valuable for future work, not for the current drafts. Tickets related to these topics will be marked "future" and will not be resolved within these documents but for future work.

This is delaying our work now so I suggest we close this discussion and re-open once we have pushed these documents through the RFC process.

Thanks!

Natasha

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

On 19 Aug 2016, at 08:18, Gunnar Hellström <[email-masked]<mailto:[email-masked]>> wrote:

/Gunnar

/Gunnar

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

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: Fri, 19 Aug 2016 17:57:39 +0200

Hi Natasha,

Please note that Issue #6 was not related to the closed topic, and that 
its latest comment had a proposal for less drastic changes than the 
original one. So it should stay open and be valid for regular 
discussions of rewording proposals for the draft.

Have a nice vacation,

/Gunnar

Den 2016-08-19 kl. 17:27, skrev Natasha Rooney:
> Hi all,
>
> The chairs (myself and Bernard) have discussed this item and I wish to 
> reiterate the same point we have made at many stages:
>
> This work is valuable for future work, not for the current drafts. 
> Tickets related to these topics will be marked "future" and will not 
> be resolved within these documents but for future work.
>
> This is delaying our work now so I suggest we close this discussion 
> and re-open once we have pushed these documents through the RFC process.
>
> Thanks!
>
> Natasha
>
>
> Natasha Rooney | Internet Engineering Director | GSMA | 
> [email-masked] <mailto:[email-masked]> | +44 (0) 7730 219 765 | 
> @thisNatasha | Skype: [email-masked] <mailto:[email-masked]>
>
>
>> On 19 Aug 2016, at 08:18, Gunnar Hellström 
>> We have been discussing it for 40 months (!), the surrounding 
>> standards requiring it have defined that they need the function but 
>> cannot go on to detail stage 3 of how to use our specification for 
>> this need.
>>
>> With the current draft I can specify that I prefer to speak English 
>> but can also with lower preference accept to speak French.
>>
>> But I cannot specify that I prefer to sign BSL (British Sign 
>> Language) but can also with lower preference accept to read and write 
>> English. I do not see any logic in making that difference. It is just 
>> an incomplete specification. And, since the examples about routing 
>> and setting up calls are preferred in this discussion, I can take a 
>> simple example from when this indication is useful:
>>
>> We have directives in force in Europe saying that all shall be 
>> equally well taken care of by emergency services.
>>
>> included in the capability indication so that calls with friends can 
>> be held in BSL without any relay service coming into the call)
>>
>> 2. Person B prefers BSL but can accept to use written English. 
>> (Written English is included in the capability indication so that 
>> calls with hearing people with text capability can be held in text 
>> without a relay service coming into the call )
>>
>> 3. An emergency service has a small group of people who communicate 
>> well in BSL and other call-takers who speak and type English.
>>
>> 4. When user B calls emergency service, the call should be routed to 
>> the small group knowing sign language well and the call should start 
>> in BSL.
>>
>> 5. When user A calls emergency service, the call should be routed to 
>> the general call-takers who have text and spoken capabilities.
>>
>> 6. With a method for preference indication between written English 
>> and BSL, the ESInet can do the routing and send each call to the 
>> group most suited to take it.
>>
>> take for the attributes, so let us try to decide on both the 
>> attribute syntax and the most favoured modality indication syntax 
>> together.
>>
>> /Gunnar
>>
>>
>>>>>>>   In order for the call to complete successfully you then need 
>>>>>> example).  What the endpoints do with this knowledge, including 
>>>>>> if and how they communicate it to the user, is out of scope.
>>>>>>
>>>>> Yes, agreed. So our task in this draft is to describe the 
>>>>> mechanism that enable the endpoints to have the information needed 
>>>>> for a successful and smooth start of the call = greeting from the 
>>>>> called party in the most appropriate language and modality.
>>>>
>>> This is not about setting up media. It is about conveying info to 
>>> the endpoints about what language to fill the media connections 
>>> with. We have said many times that media included in the offer are 
>>> wanted anyway even if they are not used for language.
>>> SDP Contents Attribute does for content types. It provides 
>>> additional information about the media to both endpoints.
>>> In our case the information provided shall be sufficient for 
>>> starting the call in an appropriate language and modality. We do not 
>>> say how the result of the negotiation is provided to the "language 
>>> generating entity", we just convey it to the endpoint ( or terminal 
>>> or UA or client, whatever we want to call it ) but the information 
>>> needs to be sufficient to give most cases proper base for the decision.
>>>> suggestions to implementers as to how to have a successful call. 
>>>>  But that needs to be an entirely separate and purely informational 
> 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.
>
>
>