Subject: [Slim] awareness to the user in the slim real-time draft

From: Gunnar Hellström <[email-masked]>
Date: Wed, 20 Jul 2016 10:23:18 +0200

Brian and all,

We had an interesting discussion in the meeting yesterday about 
indications to the user.

I said that one intention is that the result of the language negotiation 
is provided to the users and that that is already stated in the draft.

In the introduction, we have this sentence: "Both sides should be aware 
of which language was negotiated."

I agree with this statement, and that it is often a requirement for a 
successful start of the call. It is true that the indications are also 
used for routing and selection of participants and user equipment, but 
also the users need to be informed. The answering party need to start 
the call by using the agreed preferred language in the agreed preferred 
modality, otherwise the call will start in confusion.

Imagine a call from a user preferring spoken Greek, ending up at a call 
center agent capable of English and Greek. If the agent starts with a 
greeting in English instead of Greek, the calling user will get unsure 
if Greek can be used, and the call will start in uncertainty or even be 
conducted in English that the caller does not feel confident in.

This is not user interface specification. It is as simple as the 
statement in the introduction : "Both sides should be aware of which 
language was negotiated." The discussion went on saying that we do not 
specify user interfaces in IETF. And that is true, but many times we 
specify items where the user gets aware of the results of the protocol 
interaction. Examples can be call hold and release, picture size and 
orientation, remote camera movements, attended call transfer etc. So, we 
are in good company when we state that both sides are made aware of the 
outcome.

The requirement to keep the user aware of which language was negotiated 
is valid for the current scope of the draft as well as when we include 
preference across media and grouping. We can in fact not yet really 
fulfill that requirement within the current scope because we have not 
defined any way to differentiate preference between languages in 
different media. The outcome of the negotiation can still be undefined. 
We can with the current wording for example say that the caller prefers 
spoken English or written English, but not if there is any preference 
between these two providing awareness to the callee about how to start 
the call.

So, two conclusions:

*1. We need to repeat the statement about bringing awareness at a more 
protruding position in the draft**, and that is not a user interface 
specification.*

I suggest to add a sentence last in 4:

"Information on the accepted language is provided to the participants in 
the call."

and a sentence last in 6.2:

"The caller and callee should be provided with information on the 
outcome of the negotiation. This information is intended to enable them 
to start the call in a preferred language."

*2. **We cannot**avoid to **specify**preference between 
modalities.**L**eav**ing it out would leave**the negotiation 
with**undefined results in many cases and uncertainty about how to start 
the call. *

The caller may prefer to use spoken English but can accept to use 
written English, and want to express that so that no calls are missed. A 
callee with the same preferences get no clue to how to start the call 
from a negotiation resulting in that both spoken and written English are 
accepted without preference between them. A simple indication of the 
most preferred modality would solve this uncertainty in most cases.

I suggest to add an indication of most preferred language as a new 
section 6.4.

6.4 Most preferred language

A mechanism is introduced that provides information on the most 
preferred language among all language indications in the session 
description. This is done in order to provide for a definite outcome of 
the negotiation of language in most cases, and thereby an opportunity 
for the call to start in a fruitful way.

The notation for the most preferred language is a plus ('+') character 
added after the language tag in the value of the corresponding language 
attribute. The notation MAY be used independently on both communication 
directions. The order between this indication and the indication for 
advisory versus required is not relevant.

*Background*

This discussion is in line with the requirement in 3GPP TS 22.228, 
section 7.5.2.  We have no clear obligations towards 3GPP, but It would 
be good if these requirements can be fulfilled without further 
standardisation.

This is what is said in the 3GPP specification:

      7.5.2Negotiation at IM session invocation

It shall be possible for the capability negotiation to take place at the 
time of the IP multimedia session invocation. Refer to clause 7.3 for 
further details on capability negotiation on IP multimedia session 
invocation.

A UE should support negotiation of the user's desired language(s) (as 
defined in IANA [29]) and modalities for spoken, signed and written 
languages.

The system should be able to negotiate the user's desired language(s) 
and modalities, per media stream *and/or session, in order of preference*.

A service provider shall be able to pass language and modality 
information between the endpoints. With respect to the language and 
modality information, there are no other service provider actions required.

--------------------------------------------------

Regards

Gunnar

-- 
-----------------------------------------
Gunnar Hellström
Omnitor
[email-masked]

---

From: Brian Rosen <[email-masked]>
Date: Wed, 20 Jul 2016 10:50:44 +0200

I’m very sensitive to user interface issues, and have some modest experience building good ones.

I’m also pretty firm that protocol standards must not deal, in any way, with user interfaces, other than, sometimes, providing some information in protocol messages that are not strictly speaking required for the proper implementation of the protocol.

When I read a statement that “both sides should be aware of which language was negotiated”, I interpret that as the implementation (that is, the code), and not the humans.  It means that the messages in the protocol must result in both ends of the protocol knowing the result.  We do use the word “users” occasionally in protocol documents, and that’s the term I expect to see when we mean the humans. 

The document does describe a mechanism where both ends of the negotiation know the result, and thus we fulfill the requirement with no further work.  User interfaces are free to present anything they want.  I can easily describe a scenario where they do not present the results of the protocol negotiation: we may have one interpreter who is interpreting English to ASL on video, and another one who is interpreting English to Spanish text.  The ASL interpreter doesn’t doesn’t need to know what is happening in the text change and the Spanish interpreter doesn’t need to know what is happening in the ASL channel.

Thus I don’t think any further work is needed.

Brian

> On Jul 20, 2016, at 10:23 AM, Gunnar Hellström <[email-masked]> wrote:
> 
> Brian and all,
> 
> We had an interesting discussion in the meeting yesterday about indications to the user.
> 
> I said that one intention is that the result of the language negotiation is provided to the users and that that is already stated in the draft.
> 
> In the introduction, we have this sentence: "Both sides should be aware of which language was negotiated."
> 
> I agree with this statement, and that it is often a requirement for a successful start of the call. It is true that the indications are also used for routing and selection of participants and user equipment, but also the users need to be informed. The answering party need to start the call by using the agreed preferred language in the agreed preferred modality, otherwise the call will start in confusion.
> 
> Imagine a call from a user preferring spoken Greek, ending up at a call center agent capable of English and Greek. If the agent starts with a greeting in English instead of Greek, the calling user will get unsure if Greek can be used, and the call will start in uncertainty or even be conducted in English that the caller does not feel confident in. 
> 
> This is not user interface specification. It is as simple as the statement in the introduction : "Both sides should be aware of which language was negotiated."  The discussion went on saying that we do not specify user interfaces in IETF. And that is true, but many times we specify items where the user gets aware of the results of the protocol interaction. Examples can be call hold and release, picture size and orientation, remote camera movements, attended call transfer etc. So, we are in good company when we state that both sides are made aware of the outcome.
> 
> The requirement to keep the user aware of which language was negotiated is valid for the current scope of the draft as well as when we include preference across media and grouping. We can in fact not yet really fulfill that requirement within the current scope because we have not defined any way to differentiate preference between languages in different media. The outcome of the negotiation can still be undefined. We can with the current wording for example say that the caller prefers spoken English or written English, but not if there is any preference between these two providing awareness to the callee about how to start the call. 
> 
> So, two conclusions:
> 
> 1. We need to repeat the statement about bringing awareness at a more protruding position in the draft, and that is not a user interface specification.
> 
> "Information on the accepted language is provided to the participants in the call."
> 
> "The caller and callee should be provided with information on the outcome of the negotiation. This information is intended to enable them to start the call in a preferred language."
> 
> 2. We cannot avoid to specify preference between modalities. Leaving it out would leave the negotiation withundefined results in many cases and uncertainty about how to start the call. 
> 
> The caller may prefer to use spoken English but can accept to use written English, and want to express that so that no calls are missed. A callee with the same preferences get no clue to how to start the call from a negotiation resulting in that both spoken and written English are accepted without preference between them. A simple indication of the most preferred modality would solve this uncertainty in most cases.
> 
> I suggest to add an indication of most preferred language as a new section 6.4.
> 
> A mechanism is introduced that provides information on the most preferred language among all language indications in the session description. This is done in order to provide for a definite outcome of the negotiation of language in most cases, and thereby an opportunity for the call to start in a fruitful way. 
> 
> The notation for the most preferred language is a plus ('+') character added after the language tag in the value of the corresponding language attribute. The notation MAY be used independently on both communication directions. The order between this indication and the indication for advisory versus required is not relevant.
> 
> 
> 
> Background
> 
> This discussion is in line with the requirement in 3GPP TS 22.228, section 7.5.2.  We have no clear obligations towards 3GPP, but It would be good if these requirements can be fulfilled without further standardisation.
> 
> 7.5.2       Negotiation at IM session invocation <>
> It shall be possible for the capability negotiation to take place at the time of the IP multimedia session invocation. Refer to clause 7.3 for further details on capability negotiation on IP multimedia session invocation.
> 
> A UE should support negotiation of the user's desired language(s) (as defined in IANA [29]) and modalities for spoken, signed and written languages.
> 
> The system should be able to negotiate the user's desired language(s) and modalities, per media stream and/or session, in order of preference.
> 
> A service provider shall be able to pass language and modality information between the endpoints. With respect to the language and modality information, there are no other service provider actions required.
> 
> 
> [email-masked] <mailto:[email-masked]>

---

From: Bernard Aboba <[email-masked]>
Date: Wed, 20 Jul 2016 15:34:16 +0200

On Jul 20, 2016, at 10:50 AM, Brian Rosen <[email-masked]> wrote:
> 
>  User interfaces are free to present anything they want.  

[BA] To put it more concretely, a web-based application could implement the current draft in a SIP Javascript library and that library could provide an indication of what languages are enabled in each direction on each m-line. 

The web application can then use that information in any way it chooses. It could for example provide controls to enable the user to indicate both locally and remotely their media preferences.

---

From: Paul Kyzivat <[email-masked]>
Date: Wed, 20 Jul 2016 09:47:27 -0400

> The web application can then use that information in any way it chooses. It could for example provide controls to enable the user to indicate both locally and remotely their media preferences.

Yes.

Conversely, it is challenging to present this information if the UI is a 
black phone, and so the information most likely won't be presented there.

	Thanks,
	Paul

---

From: Gunnar Hellström <[email-masked]>
Date: Wed, 20 Jul 2016 16:40:12 +0200

> experience building good ones.
I am not talking about user interface issues.  Just that for successful 
operation, we have cases when the user needs to be informed. And that is 
the case already with the draft as it is now. It will not have the 
intended effect if the users are not informed.
>
> I’m also pretty firm that protocol standards must not deal, in any 
> way, with user interfaces, other than, sometimes, providing some 
> information in protocol messages that are not strictly speaking 
> required for the proper implementation of the protocol.
Right. The protocol can be executed on its own, but for many use cases 
we need to indicate to the users what the outcome was, otherwise we will 
leave them in uncertainty and they may act completely against what the 
protocol mechanism decided.
>
> When I read a statement that “both sides should be aware of which 
> language was negotiated”, I interpret that as the implementation (that 
> is, the code), and not the humans.  It means that the messages in the 
> protocol must result in both ends of the protocol knowing the result. 
>  We do use the word “users” occasionally in protocol documents, and 
> that’s the term I expect to see when we mean the humans.
Well. whatever was the intention with the sentence in the introduction, 
the users in many cases need to be informed and aware.
>
> The document does describe a mechanism where both ends of the 
> negotiation know the result, and thus we fulfill the requirement with 
> no further work.  User interfaces are free to present anything they 
> want.  I can easily describe a scenario where they do not present the 
> results of the protocol negotiation: we may have one interpreter who 
> is interpreting English to ASL on video, and another one who is 
> interpreting English to Spanish text.  The ASL interpreter doesn’t 
> doesn’t need to know what is happening in the text change and the 
> Spanish interpreter doesn’t need to know what is happening in the ASL 
> channel.
Yes, it is possible to imagine cases when it is sufficient to indicate 
to the callee that there is an incoming call that they need to act on. 
In the case that the callee has indicated *only one single language in 
one single humintlang-send attribute*, then there is no question on how 
to respond to the call. The callee simply welcomes the caller in the 
only language specified.

But we want other cases to work as well. *As soon as the callee has 
indicated capabilities in two languages, it is essential to provide 
information about the outcome of the protocol negotiation to the callee. 
*The simple case with a callee capable of both spoken and written 
English is such a case. We do not at all need to tell anything about the 
user interface, but we need to mention something about providing 
information to the user.

And in order to have a clear outcome in most cases, instead of 
ambiguity, we need at least *a notation for the most preferred language 
indication*.

How else would you be able to start the call in an appropriate way 
suiting the caller?

So, the proposals below are still valid, but you might want to fine tune 
them to fit your view of how to indicate items to the user.

/Gunnar

>> On Jul 20, 2016, at 10:23 AM, Gunnar Hellström 
>> <[email-masked] <mailto:[email-masked]>> wrote:
>>
>> Brian and all,
>>
>> I said that one intention is that the result of the language 
>> negotiation is provided to the users and that that is already stated 
>> in the draft.
>>
>> In the introduction, we have this sentence: "Both sidesshould be 
>> aware of which language was negotiated."
>>
>> successful start of the call. It is true that the indications are 
>> also used for routing and selection of participants and user 
>> equipment, but also the users need to be informed. The answering 
>> party need to start the call by using the agreed preferred language 
>> in the agreed preferred modality, otherwise the call will start in 
>> confusion.
>>
>> Imagine a call from a user preferring spoken Greek, ending up at a 
>> call center agent capable of English and Greek. If the agent starts 
>> with a greeting in English instead of Greek, the calling user will 
>> get unsure if Greek can be used, and the call will start in 
>> uncertainty or even be conducted in English that the caller does not 
>> feel confident in.
>>
>> statement in the introduction :"Both sidesshould be aware of which 
>> language was negotiated." The discussion went on saying that we do 
>> not specify user interfaces in IETF. And that is true, but many times 
>> we specify items where the user gets aware of the results of the 
>> protocol interaction. Examples can be call hold and release, picture 
>> size and orientation, remote camera movements, attended call transfer 
>> etc. So, we are in good company when we state that both sides are 
>> made aware of the outcome.
>>
>> The requirement to keep the user aware of which language was 
>> negotiated is valid for the current scope of the draft as well as 
>> when we include preference across media and grouping. We can in fact 
>> not yet really fulfill that requirement within the current scope 
>> because we have not defined any way to differentiate preference 
>> between languages in different media. The outcome of the negotiation 
>> can still be undefined. We can with the current wording for example 
>> say that the caller prefers spoken English or written English, but 
>> not if there is any preference between these two providing awareness 
>> to the callee about how to start the call.
>>
>> So, two conclusions:
>>
>> *1. We need to repeat the statement about bringing awareness at a 
>> more protruding position in the draft**, and that is not a user 
>> interface specification.*
>>
>> outcome of the negotiation. This information is intended to enable 
>> them to start the call in a preferred language."
>>
>> *2.**We cannot**avoid to**specify**preference between 
>> with**undefined results in many cases and uncertainty about how to 
>> start the call.*
>>
>> written English, and want to express that so that no calls are 
>> missed. A callee with the same preferences get no clue to how to 
>> start the call from a negotiation resulting in that both spoken and 
>> written English are accepted without preference between them. A 
>> simple indication of the most preferred modality would solve this 
>> uncertainty in most cases.
>>
>> description. This is done in order to provide for a definite outcome 
>> of the negotiation of language in most cases, and thereby an 
>> opportunity for the call to start in a fruitful way.
>>
>> The notation for the most preferred language is a plus ('+') 
>> character added after the language tag in the value of the 
>> corresponding language attribute. The notation MAY be used 
>> independently on both communication directions. The order between 
>> this indication and the indication for advisory versus required is 
>> not relevant.
>>
>>
>> *Background*
>>
>> section 7.5.2. We have no clear obligations towards 3GPP, but It 
>> would be good if these requirements can be fulfilled without further 
>> standardisation.
>>
>> It shall be possible for the capability negotiation to take place at 
>> the time of the IP multimedia session invocation. Refer to clause 7.3 
>> for further details on capability negotiation on IP multimedia 
>> session invocation.
>>
>> defined inIANA [29])and modalities for spoken, signed and written 
>> languages.
>>
>> and modalities, per media stream*and/or session, in order of preference*.
>>
>> A service provider shall be able to pass language and 
>> modalityinformation between the endpoints. With respect to the 
>> language and modalityinformation, there are no other service provider 
>> actions required.
>>
>>
> _______________________________________________
> SLIM mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/slim

+46 708 204 288

---

From: Brian Rosen <[email-masked]>
Date: Wed, 20 Jul 2016 16:58:37 +0200

We are not communicating :)

Since the protocol mechanism described informs both ends of the result of the negotiation, no further text is needed to fulfill the requirement.
You want to go beyond what the requirement states.  

I think the statement “As soon as the callee has indicated capabilities in two languages, it is essential to provide information about the outcome of the protocol negotiation to the callee” is not always correct, and is a user interface issue, not a protocol issue.  The protocol exchange provides all the results to both ends, and any implementation is free to show any or all of that information, in any form it wants, to the human.  It is not appropriate for us to say what it should do; that is very implementation dependent.  

I specifically object to “a notation for the most preferred language”, which, strictly speaking, we have (order, per media).  You want that per session, and I object to doing that.  I strongly object to twisting “both sides should be aware…” into a requirement to transport a preference in language per session.

Brian

> On Jul 20, 2016, at 4:40 PM, Gunnar Hellström <[email-masked]> wrote:
> 
> I am not talking about user interface issues.  Just that for successful operation, we have cases when the user needs to be informed. And that is the case already with the draft as it is now. It will not have the intended effect if the users are not informed.
>> 
> Right. The protocol can be executed on its own, but for many use cases we need to indicate to the users what the outcome was, otherwise we will leave them in uncertainty and they may act completely against what the protocol mechanism decided. 
>> 
> Well. whatever was the intention with the sentence in the introduction, the users in many cases need to be informed and aware.
>> 
> Yes, it is possible to imagine cases when it is sufficient to indicate to the callee that there is an incoming call that they need to act on. In the case that the callee has indicated only one single language in one single humintlang-send attribute, then there is no question on how to respond to the call. The callee simply welcomes the caller in the only language specified. 
> 
> But we want other cases to work as well. As soon as the callee has indicated capabilities in two languages, it is essential to provide information about the outcome of the protocol negotiation to the callee. The simple case with a callee capable of both spoken and written English is such a case. We do not at all need to tell anything about the user interface, but we need to mention something about providing information to the user.  
> 
> And in order to have a clear outcome in most cases, instead of ambiguity, we need at least a notation for the most preferred language indication.
> 
> How else would you be able to start the call in an appropriate way suiting the caller?
> 
> So, the proposals below are still valid, but you might want to fine tune them to fit your view of how to indicate items to the user.
> 
> /Gunnar
> 
>> 
>>> On Jul 20, 2016, at 10:23 AM, Gunnar Hellström <[email-masked] <mailto:[email-masked]>> wrote:
>>> 
>>> Brian and all,
>>> 
>> [email-masked] <mailto:[email-masked]>
>> https://www.ietf.org/mailman/listinfo/slim <https://www.ietf.org/mailman/listinfo/slim>
> 
> -- 
> [email-masked] <mailto:[email-masked]>
> https://www.ietf.org/mailman/listinfo/slim <https://www.ietf.org/mailman/listinfo/slim>

---

From: Gunnar Hellström <[email-masked]>
Date: Wed, 20 Jul 2016 18:11:38 +0200

Den 2016-07-20 kl. 16:58, skrev Brian Rosen:

> Since the protocol mechanism described informs both ends of the result 
> of the negotiation, no further text is needed to fulfill the requirement.
> I think the statement “*As soon as the callee has indicated 
> capabilities in two languages, it is essential to provide information 
> about the outcome of the protocol negotiation to the callee*” is not 
> always correct, and is a user interface issue, not a protocol issue. 
>  The protocol exchange provides all the results to both ends, and any 
> implementation is free to show any or all of that information, in any 
> form it wants, to the human.  It is not appropriate for us to say what 
> it should do; that is very implementation dependent.
> I specifically object to “a notation for the most preferred language”, 
> which, strictly speaking, we have (order, per media).  You want that 
> per session, and I object to doing that.  I strongly object to 
> twisting “both sides should be aware…” into a requirement to transport 
> a preference in language per session.

Why don't you want to solve the human problem to start a call in the 
most effective way.
My view is that we work on a draft that can be used for negotiation of 
language in a real-time call. In many cases the successful application 
involves providing guidance to the users so they know how to start the 
call. We do not need to say when and how that shall be done, but we need 
to make sure that the involved endpoints can have sufficient information 
for provision to the user in case it is needed to get a successful start 
of the human language use in the session.

The 3GPP requirement is for a preference per session and per media. We 
have some intentions to make the slim output usable to 3GPP, so why do 
you want to stop half-way?  What makes the preference indication per 
session so hard to accept when that is what is needed to complete the 
negotiation to provide a defined outcome in a majority of cases?

Since we have the phrase about awareness in the introduction, my 
proposals under 1. below are not strictly needed, but clarifying.
The issue under point 2. is much more important for successful starts of 
calls.   If we do not solve it here, how do you then propose to solve it?

Gunnar
>
> Brian
>
>
>> On Jul 20, 2016, at 4:40 PM, Gunnar Hellström 
>> I am not talking about user interface issues.  Just that for 
>> successful operation, we have cases when the user needs to be 
>> informed. And that is the case already with the draft as it is now. 
>> It will not have the intended effect if the users are not informed.
>>>
>> Right. The protocol can be executed on its own, but for many use 
>> cases we need to indicate to the users what the outcome was, 
>> otherwise we will leave them in uncertainty and they may act 
>> completely against what the protocol mechanism decided.
>>>
>>> language was negotiated”, I interpret that as the implementation 
>>> (that is, the code), and not the humans.  It means that the messages 
>>> in the protocol must result in both ends of the protocol knowing the 
>>> result.  We do use the word “users” occasionally in protocol 
>>> documents, and that’s the term I expect to see when we mean the humans.
>> Well. whatever was the intention with the sentence in the 
>> introduction, the users in many cases need to be informed and aware.
>>>
>>> negotiation know the result, and thus we fulfill the requirement 
>>> with no further work.  User interfaces are free to present anything 
>>> they want.  I can easily describe a scenario where they do not 
>>> present the results of the protocol negotiation: we may have one 
>>> interpreter who is interpreting English to ASL on video, and another 
>>> one who is interpreting English to Spanish text.  The ASL 
>>> interpreter doesn’t doesn’t need to know what is happening in the 
>>> text change and the Spanish interpreter doesn’t need to know what is 
>>> happening in the ASL channel.
>> Yes, it is possible to imagine cases when it is sufficient to 
>> indicate to the callee that there is an incoming call that they need 
>> to act on. In the case that the callee has indicated*only one single 
>> language in one single humintlang-send attribute*, then there is no 
>> question on how to respond to the call. The callee simply welcomes 
>> the caller in the only language specified.
>>
>> But we want other cases to work as well.*As soon as the callee has 
>> information about the outcome of the protocol negotiation to the 
>> callee.*The simple case with a callee capable of both spoken and 
>> written English is such a case. We do not at all need to tell 
>> anything about the user interface, but we need to mention something 
>> about providing information to the user.
>>
>> ambiguity, we need at least*a notation for the most preferred 
>> language indication*.
>>
>> So, the proposals below are still valid, but you might want to fine 
>> tune them to fit your view of how to indicate items to the user.
>>
>> /Gunnar
>>
>>>
>>>> negotiation is provided to the users and that that is already 
>>>> stated in the draft.
>>>>
>>>> I agree with this statement, and that it is often a requirement for 
>>>> a successful start of the call. It is true that the indications are 
>>>> uncertainty or even be conducted in English that the caller does 
>>>> not feel confident in.
>>>>
>>>> not specify user interfaces in IETF. And that is true, but many 
>>>> times we specify items where the user gets aware of the results of 
>>>> the protocol interaction. Examples can be call hold and release, 
>>>> picture size and orientation, remote camera movements, attended 
>>>> call transfer etc. So, we are in good company when we state that 
>>>> both sides are made aware of the outcome.
>>>>
>>>> when we include preference across media and grouping. We can in 
>>>> fact not yet really fulfill that requirement within the current 
>>>> scope because we have not defined any way to differentiate 
>>>> preference between languages in different media. The outcome of the 
>>>> negotiation can still be undefined. We can with the current wording 
>>>> for example say that the caller prefers spoken English or written 
>>>> English, but not if there is any preference between these two 
>>>> providing awareness to the callee about how to start the call.
>>>>
>>>> So, two conclusions:
>>>>
>>>> description. This is done in order to provide for a definite 
>>>> outcome of the negotiation of language in most cases, and thereby 
>>>> an opportunity for the call to start in a fruitful way.
>>>>
>>>> would be good if these requirements can be fulfilled without 
>>>> further standardisation.
>>>>
>>>> It shall be possible for the capability negotiation to take place 
>>>> at the time of the IP multimedia session invocation. Refer to 
>>>> clause 7.3 for further details on capability negotiation on IP 
>>>> multimedia session invocation.
>>>>
>>>> A UE should support negotiation of the user's desired language(s) 
>>>> (as defined inIANA [29])and modalities for spoken, signed and 
>>>> written languages.
>>>>
>>>> The system should be able to negotiate the user's desired 
>>>> language(s) and modalities, per media stream*and/or session, in 
>>>> order of preference*.
>>>>
>>>> language and modalityinformation, there are no other service 
>>>> provider actions required.
>>>>
>>>>

---

From: Brian Rosen <[email-masked]>
Date: Wed, 20 Jul 2016 18:18:54 +0200

I believe we had a consensus call on not including per session preferences in this document.  Chairs can correct me if I am misremembering or misinterpreting what happened.

Anyone can write a draft.  If you want to propose a solution to that problem, go ahead, and write a draft.  I would oppose adding that capability to this document.

I don’t think we need to, or want to, specify any implementation advice with regard to user interfaces. I think “provide information….to the callee” is a user interface issue.

Brian
> On Jul 20, 2016, at 6:11 PM, Gunnar Hellström <[email-masked]> wrote:
> 
> Why don't you want to solve the human problem to start a call in the most effective way. 
> My view is that we work on a draft that can be used for negotiation of language in a real-time call. In many cases the successful application involves providing guidance to the users so they know how to start the call. We do not need to say when and how that shall be done, but we need to make sure that the involved endpoints can have sufficient information for provision to the user in case it is needed to get a successful start of the human language use in the session.
> 
> The 3GPP requirement is for a preference per session and per media. We have some intentions to make the slim output usable to 3GPP, so why do you want to stop half-way?  What makes the preference indication per session so hard to accept when that is what is needed to complete the negotiation to provide a defined outcome in a majority of cases? 
> 
> Since we have the phrase about awareness in the introduction, my proposals under 1. below are not strictly needed, but clarifying. 
> The issue under point 2. is much more important for successful starts of calls.   If we do not solve it here, how do you then propose to solve it?
> 
> Gunnar
>> 
>> Brian
>> 
>> 
>>> On Jul 20, 2016, at 4:40 PM, Gunnar Hellström <[email-masked] <mailto:[email-masked]>> wrote:
>>>

---

From: Gunnar Hellström <[email-masked]>
Date: Wed, 20 Jul 2016 18:39:10 +0200

Den 2016-07-20 kl. 18:18, skrev Brian Rosen:
> I believe we had a consensus call on not including per session 
> preferences in this document.  Chairs can correct me if I am 
> misremembering or misinterpreting what happened.
The discussion in the meeting indicated that you viewed the preference 
across media as something very different from the other indications, 
while it is not, and also needed to get a finite result of the 
negotiation. With that new knowledge about earlier miscommunication or 
whatever it was, I claim that we include it.

Gunnar
>
> Anyone can write a draft.  If you want to propose a solution to that 
> problem, go ahead, and write a draft.  I would oppose adding that 
> capability to this document.
>
> I don’t think we need to, or want to, specify any implementation 
> advice with regard to user interfaces. I think “provide 
> information….to the callee” is a user interface issue.
>
> Brian
>> On Jul 20, 2016, at 6:11 PM, Gunnar Hellström 
>>> Since the protocol mechanism described informs both ends of the 
>>> result of the negotiation, no further text is needed to fulfill the 
>>> requirement.
>>> capabilities in two languages, it is essential to provide 
>>> callee*” is not always correct, and is a user interface issue, not a 
>>> protocol issue.  The protocol exchange provides all the results to 
>>> both ends, and any implementation is free to show any or all of that 
>>> information, in any form it wants, to the human.  It is not 
>>> appropriate for us to say what it should do; that is very 
>>> implementation dependent.
>>> I specifically object to “a notation for the most preferred 
>>> language”, which, strictly speaking, we have (order, per media). 
>>>  You want that per session, and I object to doing that.  I strongly 
>>> object to twisting “both sides should be aware…” into a requirement 
>>> to transport a preference in language per session.
>>
>> My view is that we work on a draft that can be used for negotiation 
>> of language in a real-time call. In many cases the successful 
>> application involves providing guidance to the users so they know how 
>> to start the call. We do not need to say when and how that shall be 
>> done, but we need to make sure that the involved endpoints can have 
>> sufficient information for provision to the user in case it is needed 
>> to get a successful start of the human language use in the session.
>>
>> The 3GPP requirement is for a preference per session and per media. 
>> We have some intentions to make the slim output usable to 3GPP, so 
>> why do you want to stop half-way? What makes the preference 
>> indication per session so hard to accept when that is what is needed 
>> to complete the negotiation to provide a defined outcome in a 
>> majority of cases?
>>
>> The issue under point 2. is much more important for successful starts 
>> of calls.   If we do not solve it here, how do you then propose to 
>> solve it?
>>
>> Gunnar
>>>
>>> Brian
>>>
>>>
>>>>> (that is, the code), and not the humans.  It means that the 
>>>>> messages in the protocol must result in both ends of the protocol 
>>>>> knowing the result.  We do use the word “users” occasionally in 
>>>>> protocol documents, and that’s the term I expect to see when we 
>>>>> mean the humans.
>>>>> with no further work.  User interfaces are free to present 
>>>>> anything they want.  I can easily describe a scenario where they 
>>>>> do not present the results of the protocol negotiation: we may 
>>>>> have one interpreter who is interpreting English to ASL on video, 
>>>>> and another one who is interpreting English to Spanish text.  The 
>>>>> ASL interpreter doesn’t doesn’t need to know what is happening in 
>>>>> the text change and the Spanish interpreter doesn’t need to know 
>>>>> what is happening in the ASL channel.
>>>> indicate to the callee that there is an incoming call that they 
>>>> need to act on. In the case that the callee has indicated*only one 
>>>> single language in one single humintlang-send attribute*, then 
>>>> there is no question on how to respond to the call. The callee 
>>>> simply welcomes the caller in the only language specified.
>>>>
>>>>>> <[email-masked] 
>>>>>> <mailto:[email-masked]>> wrote:
>>>>>>
>>>>>> Brian and all,
>>>>>>
>>>>>> I agree with this statement, and that it is often a requirement 
>>>>>> for a successful start of the call. It is true that the 
>>>>>> indications are also used for routing and selection of 
>>>>>> participants and user equipment, but also the users need to be 
>>>>>> informed. The answering party need to start the call by using the 
>>>>>> agreed preferred language in the agreed preferred modality, 
>>>>>> otherwise the call will start in confusion.
>>>>>>
>>>>>> Imagine a call from a user preferring spoken Greek, ending up at 
>>>>>> a call center agent capable of English and Greek. If the agent 
>>>>>> starts with a greeting in English instead of Greek, the calling 
>>>>>> user will get unsure if Greek can be used, and the call will 
>>>>>> start in uncertainty or even be conducted in English that the 
>>>>>> caller does not feel confident in.
>>>>>>
>>>>>> statement in the introduction :"Both sidesshould be aware of 
>>>>>> which language was negotiated." The discussion went on saying 
>>>>>> that we do not specify user interfaces in IETF. And that is true, 
>>>>>> but many times we specify items where the user gets aware of the 
>>>>>> results of the protocol interaction. Examples can be call hold 
>>>>>> and release, picture size and orientation, remote camera 
>>>>>> movements, attended call transfer etc. So, we are in good company 
>>>>>> when we state that both sides are made aware of the outcome.
>>>>>>
>>>>>> preference between languages in different media. The outcome of 
>>>>>> the negotiation can still be undefined. We can with the current 
>>>>>> wording for example say that the caller prefers spoken English or 
>>>>>> written English, but not if there is any preference between these 
>>>>>> two providing awareness to the callee about how to start the call.
>>>>>>
>>>>>> So, two conclusions:
>>>>>>
>>>>>> outcome of the negotiation. This information is intended to 
>>>>>> enable them to start the call in a preferred language."
>>>>>>
>>>>>> with**undefined results in many cases and uncertainty about how 
>>>>>> to start the call.*
>>>>>>
>>>>>> start the call from a negotiation resulting in that both spoken 
>>>>>> and written English are accepted without preference between them. 
>>>>>> A simple indication of the most preferred modality would solve 
>>>>>> this uncertainty in most cases.
>>>>>>
>>>>>> this indication and the indication for advisory versus required 
>>>>>> is not relevant.
>>>>>>
>>>>>>
>>>>>> *Background*
>>>>>>
>>>>>> This discussion is in line with the requirement in 3GPP TS 
>>>>>> 22.228, section 7.5.2.  We have no clear obligations towards 
>>>>>> 3GPP, but It would be good if these requirements can be fulfilled 
>>>>>> without further standardisation.
>>>>>>

---

From: Bernard Aboba <[email-masked]>
Date: Wed, 20 Jul 2016 18:52:28 +0200

> Why don't you want to solve the human problem to start a call in the most effective way. 

[BA] As stated at the meeting, the major question is in what layer this functionality belongs.

In several IETF WGs, including CLUE and now WEBRTC, the decision has been made to limit the complexity of the SDP O/A negotiation to the bare minimum needed to bring the call up. From there, the application can add functionality. This approach "optimizes for the common case",  limits the difficulty in implementing the basic required SDP and makes it more likely that it will interoperate.

AFAICT, the basic SDP functionality in the draft appears to be enough to enable an application to handle media preference on its own. 

As an example, I believe that every use case can be supported within a web application using a modified SIP library without any SDP additions beyond what we already have defined.

Yes, the application would need to deal with media preferences but most unified communications applications support multiple modes and need to handle decisions on media usage already (camera on/off, mute, etc.) Adding complexity to the SDP parser might actually make it harder for the application, not easier.

---

From: Brian Rosen <[email-masked]>
Date: Wed, 20 Jul 2016 19:01:29 +0200

I do not believe that is the case.  

I think I’ve represented my point of view sufficiently clearly, and I don’t have anything to add.  I don’t want more mechanism than the current draft provides.

In the absence of any really new information, I think I’m done with this thread.

Brian

> On Jul 20, 2016, at 6:39 PM, Gunnar Hellström <[email-masked]> wrote:
> 
> The discussion in the meeting indicated that you viewed the preference across media as something very different from the other indications, while it is not, and also needed to get a finite result of the negotiation. With that new knowledge about earlier miscommunication or whatever it was, I claim that we include it.
> 
> Gunnar
>> 
>>> On Jul 20, 2016, at 6:11 PM, Gunnar Hellström <[email-masked] <mailto:[email-masked]>> wrote:
>>>

---

From: Gunnar Hellström <[email-masked]>
Date: Thu, 21 Jul 2016 09:15:27 +0200

Bernard, thanks for trying to explain the resistance.

> [BA] As stated at the meeting, the major question is in what layer this functionality belongs.
I guess you mean the whole topic of language negotiation. It is an 
application level topic about user information and agreement, with some 
influence on call routing and device selection.
If you meant the remaining issues of preference across session, and 
grouping, it is the same.
> In several IETF WGs, including CLUE and now WEBRTC, the decision has been made to limit the complexity of the SDP O/A negotiation to the bare minimum needed to bring the call up. From there, the ap…
Yes, sdp is becoming hard to manage, when you are supposed to negotiate 
SRTP vs RTP, AVPF vs AVP, RTCP vs INFO, multiplexing, ICE etc and now 
also language. So, maybe we made the wrong decision to go this way. We 
could have defined an XML schema for language and modality preferences 
and conveyed it somehow between the parties. But now we are here with 
our decision close to WGLC and intend to take this through.
> As an example, I believe that every use case can be supported within a web application using a modified SIP library without any SDP additions beyond what we already have defined.
Do you mean that we now need to add SIP headers for the remaining 
information to really sort out what it meant by the limited indications 
we provide in SDP.

Something like: modality-preference-send: speech ; 
modality-preference-recv: speech

And something similar for SIP-less calls?

> Yes, the application would need to deal with media preferences but most unified communications applications support multiple modes and need to handle decisions on media usage already (camera on/off…
The application areas I want to see benefit from this work are wide and 
do not have any other common specification fora that can add SIP or SDP 
elements. It is for example 3GPP that convey regular calls with ambition 
to have interoperability between providers, and it is for example 
between SIP providers and ESiNets following NENA or EENA specs. They all 
rely on the ground work done in IETF, for selection into their profiles.

It is possible to make another IETF draft and add the missing parts 
there, but it looks unmotivated to break out a small part of the work 
like that.

What I want to avoid is this situation:

-Caller calls with indication of English speech reception and English 
text reception
  Caller prefers speech, but has included text for not scaring off 
friends who prefer text. But there is no way to convey this preference.
-Callee has both English speech sending and English text sending capability.
-Callee has no clue for how to start the call, so just taking a chance, 
the callee starts in text, typing "Hi, welcome to my service".
-The caller sees that and feels that it is most polite to start in the 
same modality, so the caller thinks it is a bit inconvenient, but types: 
" Hi, I want support for a problem. Can we talk?"
-The callee types: "Oh, yes, let us switch to talking" and the the 
callee says "Ok , talking now, what is your problem."
- The call continues in speech, using text just for model numbers, 
booking numbers URL:s etc in this case.

This is a quite natural development of a call where preference is not 
indicated from the beginning, and it adds inconvenience and delay 
compared to what it could have been if there was a way to convey 
modality preference.

I think it is small enough feature to go into the humintlang draft and 
general enough to not be pushed to be solved differently for each 
application.

A thought of mine was that the asterisk-notation for "do not fail" was 
not really needed and we could move that notation to point out the most 
preferred modality. But we heard opposition to that in the meeting, so 
now we are back to the need to add something small but important.

/Gunnar

---

From: Randall Gellens <[email-masked]>
Date: Thu, 21 Jul 2016 02:04:20 -0700

You want the application to be able to first know 
what the user prefers across all media and 
languages, and second, to be able to match what 
was negotiated with the other end with what the 
user wants.  I believe you can do that with what 
we have now.

Consider: the application takes into account the 
user's preferences across media and languages in 
deciding what to offer.  After the session is 
established, the application compares what was 
accepted to the user's preferences across media 
and languages, determines which combination of 
the accepted media and languages is most 
preferred by the user, and displays that 
information to the user.

--Randy

At 9:15 AM +0200 7/21/16, Gunnar Hellström wrote:

>> <[email-masked]> wrote:
>>>  Why don't you want to solve the human problem 
>>> to start a call in the most effective way.
>>  [BA] As stated at the meeting, the major 
>> question is in what layer this functionality 
>> belongs.
>  I guess you mean the whole topic of language 
> negotiation. It is an application level topic 
> about user information and agreement, with some 
>  If you meant the remaining issues of preference 
> across session, and grouping, it is the same.
>>
>>  In several IETF WGs, including CLUE and now 
>> WEBRTC, the decision has been made to limit 
>> the complexity of the SDP O/A negotiation to 
>> the bare minimum needed to bring the call up. 
>> From there, the application can add 
>> functionality. This approach "optimizes for 
>> the common case",  limits the difficulty in 
>> implementing the basic required SDP and makes 
>> it more likely that it will interoperate.
>  Yes, sdp is becoming hard to manage, when you 
> are supposed to negotiate SRTP vs RTP, AVPF vs 
> AVP, RTCP vs INFO, multiplexing, ICE etc and 
> now also language. So, maybe we made the wrong 
> decision to go this way. We could have defined 
> an XML schema for language and modality 
> preferences and conveyed it somehow between the 
> parties. But now we are here with our decision 
> close to WGLC and intend to take this through.
>>
>>  AFAICT, the basic SDP functionality in the 
>> draft appears to be enough to enable an 
>> application to handle media preference on its 
>> own.
>>
>>  As an example, I believe that every use case 
>> can be supported within a web application 
>> using a modified SIP library without any SDP 
>> additions beyond what we already have defined.
>  Do you mean that we now need to add SIP headers 
> for the remaining information to really sort 
> out what it meant by the limited indications we 
> provide in SDP.
>
>  Something like: modality-preference-send: 
> speech ; modality-preference-recv: speech
>
>>  Yes, the application would need to deal with 
>> media preferences but most unified 
>> communications applications support multiple 
>> modes and need to handle decisions on media 
>> usage already (camera on/off, mute, etc.) 
>> Adding complexity to the SDP parser might 
>> actually make it harder for the application, 
>> not easier.
>  The application areas I want to see benefit 
> from this work are wide and do not have any 
> other common specification fora that can add 
> SIP or SDP elements. It is for example 3GPP 
> that convey regular calls with ambition to have 
> interoperability between providers, and it is 
> for example between SIP providers and ESiNets 
> following NENA or EENA specs. They all rely on 
> the ground work done in IETF, for selection 
> into their profiles.
>
>  It is possible to make another IETF draft and 
> add the missing parts there, but it looks 
> unmotivated to break out a small part of the 
> work like that.
>
>  -Caller calls with indication of English speech 
> reception and English text reception
>   Caller prefers speech, but has included text 
> for not scaring off friends who prefer text. 
> But there is no way to convey this preference.
>  -Callee has no clue for how to start the call, 
> so just taking a chance, the callee starts in 
> text, typing "Hi, welcome to my service".
>  -The caller sees that and feels that it is most 
> polite to start in the same modality, so the 
> caller thinks it is a bit inconvenient, but 
> types: " Hi, I want support for a problem. Can 
> we talk?"
>  -The callee types: "Oh, yes, let us switch to 
> talking" and the the callee says "Ok , talking 
> now, what is your problem."
>  - The call continues in speech, using text just 
> for model numbers, booking numbers URL:s etc in 
> this case.
>
>  This is a quite natural development of a call 
> where preference is not indicated from the 
> beginning, and it adds inconvenience and delay 
> compared to what it could have been if there 
> was a way to convey modality preference.
>
>  I think it is small enough feature to go into 
> the humintlang draft and general enough to not 
> be pushed to be solved differently for each 
> application.
>
>  A thought of mine was that the 
> asterisk-notation for "do not fail" was not 
> really needed and we could move that notation 
> to point out the most preferred modality. But 
> we heard opposition to that in the meeting, so 

-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly selected tag: ---------------
If A = B and B = C, then A = C, except where void or prohibited by law.

---

From: Gunnar Hellström <[email-masked]>
Date: Thu, 21 Jul 2016 14:53:26 +0200

Den 2016-07-21 kl. 11:04, skrev Randall Gellens:
> You want the application to be able to first know what the user 
> prefers across all media and languages, and second, to be able to 
> match what was negotiated with the other end with what the user 
> wants.  I believe you can do that with what we have now.
>
> Consider: the application takes into account the user's preferences 
> across media and languages in deciding what to offer. After the 
> session is established, the application compares what was accepted to 
> the user's preferences across media and languages, determines which 
> combination of the accepted media and languages is most preferred by 
> the user, and displays that information to the user.
It is not sufficient. We have not defined any way to convey e.g. that 
spoken language is preferred over written language.

The called party want to start the conversation with a greeting in the 
language and the modality that the caller prefers ( if that reasonably 
matches the callee capabilities ).

So assume that the caller can use spoken English and written English and 
strongly prefers the spoken English.

These capabilities can both be indicated in the offer but without any 
preference indication .

That leaves the callee without a clue on how to answer to not cause 
initial confusion.

That is the simple case I want a notation for. Just a highest preference 
mark to hook on e.g. to the spoken English indication.

One notation was just proposed in another mail to be included as section 
6.4.

Gunnar
>> application level topic about user information and agreement, with 
>> some influence on call routing and device selection.
>>>  In several IETF WGs, including CLUE and now WEBRTC, the decision 
>>> has been made to limit the complexity of the SDP O/A negotiation to 
>>> the bare minimum needed to bring the call up. From there, the 
>>> application can add functionality. This approach "optimizes for the 
>>> common case",  limits the difficulty in implementing the basic 
>>> required SDP and makes it more likely that it will interoperate.
>>  Yes, sdp is becoming hard to manage, when you are supposed to 
>> negotiate SRTP vs RTP, AVPF vs AVP, RTCP vs INFO, multiplexing, ICE 
>> etc and now also language. So, maybe we made the wrong decision to go 
>> this way. We could have defined an XML schema for language and 
>> modality preferences and conveyed it somehow between the parties. But 
>> now we are here with our decision close to WGLC and intend to take 
>> this through.
>>>
>>>  AFAICT, the basic SDP functionality in the draft appears to be 
>>> enough to enable an application to handle media preference on its own.
>>>
>>>  As an example, I believe that every use case can be supported 
>>> within a web application using a modified SIP library without any 
>>> SDP additions beyond what we already have defined.
>> information to really sort out what it meant by the limited 
>> indications we provide in SDP.
>>
>>>  Yes, the application would need to deal with media preferences but 
>>> most unified communications applications support multiple modes and 
>>> need to handle decisions on media usage already (camera on/off, 
>>> mute, etc.) Adding complexity to the SDP parser might actually make 
>>> it harder for the application, not easier.
>>  The application areas I want to see benefit from this work are wide 
>> and do not have any other common specification fora that can add SIP 
>> or SDP elements. It is for example 3GPP that convey regular calls 
>> with ambition to have interoperability between providers, and it is 
>> for example between SIP providers and ESiNets following NENA or EENA 
>> specs. They all rely on the ground work done in IETF, for selection 
>> into their profiles.
>>
>>  -Caller calls with indication of English speech reception and 
>> English text reception
>>  -Callee has no clue for how to start the call, so just taking a 
>> chance, the callee starts in text, typing "Hi, welcome to my service".
>>  -The caller sees that and feels that it is most polite to start in 
>> the same modality, so the caller thinks it is a bit inconvenient, but 
>> types: " Hi, I want support for a problem. Can we talk?"
>>  This is a quite natural development of a call where preference is 
>> not indicated from the beginning, and it adds inconvenience and delay 
>>  I think it is small enough feature to go into the humintlang draft 
>> and general enough to not be pushed to be solved differently for each 
>> application.
>>
>>  A thought of mine was that the asterisk-notation for "do not fail" 
>> was not really needed and we could move that notation to point out 
>> the most preferred modality. But we heard opposition to that in the 
>> meeting, so now we are back to the need to add something small but 
>> important.
>>
>>  /Gunnar
>>
>>>
>>>
>>>
>>>

---

From: Randall Gellens <[email-masked]>
Date: Thu, 21 Jul 2016 06:09:31 -0700

At 2:53 PM +0200 7/21/16, Gunnar Hellström wrote:

>>  You want the application to be able to first 
>> know what the user prefers across all media 
>> and languages, and second, to be able to match 
>> what was negotiated with the other end with 
>> what the user wants.  I believe you can do 
>> that with what we have now.
>>
>>  Consider: the application takes into account 
>> the user's preferences across media and 
>> languages in deciding what to offer. After the 
>> session is established, the application 
>> compares what was accepted to the user's 
>> preferences across media and languages, 
>> determines which combination of the accepted 
>> media and languages is most preferred by the 
>> user, and displays that information to the 
>> user.
>  It is not sufficient. We have not defined any 
> way to convey e.g. that spoken language is 
> preferred over written language.

Conveying the information from the application to 
the user is out of scope.  Conveying the 
information from one client to another is not 
needed.

>
>  The called party want to start the conversation 
> with a greeting in the language and the 
> modality that the caller prefers ( if that 
> reasonably matches the callee capabilities ).
>
>  So assume that the caller can use spoken 
> English and written English and strongly 
> prefers the spoken English.
>
>  These capabilities can both be indicated in the 
> offer but without any preference indication .
>
>  That leaves the callee without a clue on how to 
> answer to not cause initial confusion.

The callee answers with whichever of the 
requested media and language streams it can 
support.

>
>  That is the simple case I want a notation for. 
> Just a highest preference mark to hook on e.g. 
> to the spoken English indication.
>
>  One notation was just proposed in another mail to be included as section 6.4.
>
>  Gunnar
>>
>>  --Randy
>>
>>
>>>>   On Jul 20, 2016, at 6:11 PM, Gunnar 
>>>> Hellström <[email-masked]> 
>>>> wrote:
>>>>>   Why don't you want to solve the human 
>>>>> problem to start a call in the most 
>>>>> effective way.
>>> about user information and agreement, with 
>>>   If you meant the remaining issues of 
>>> preference across session, and grouping, it 
>>> is the same.
>>>>
>>>> the bare minimum needed to bring the call 
>>>> up. From there, the application can add 
>>>> implementing the basic required SDP and 
>>>> makes it more likely that it will 
>>>> interoperate.
>>>   Yes, sdp is becoming hard to manage, when 
>>> you are supposed to negotiate SRTP vs RTP, 
>>> AVPF vs AVP, RTCP vs INFO, multiplexing, ICE 
>>> etc and now also language. So, maybe we made 
>>> the wrong decision to go this way. We could 
>>> have defined an XML schema for language and 
>>> modality preferences and conveyed it somehow 
>>> between the parties. But now we are here with 
>>>> application to handle media preference on 
>>>> its own.
>>>>
>>>>   As an example, I believe that every use 
>>>> case can be supported within a web 
>>>> application using a modified SIP library 
>>>> without any SDP additions beyond what we 
>>>> already have defined.
>>>   Do you mean that we now need to add SIP 
>>> headers for the remaining information to 
>>> really sort out what it meant by the limited 
>>>>   Yes, the application would need to deal 
>>>> with media preferences but most unified 
>>> that convey regular calls with ambition to 
>>> have interoperability between providers, and 
>>> it is for example between SIP providers and 
>>> ESiNets following NENA or EENA specs. They 
>>> all rely on the ground work done in IETF, for 
>>> selection into their profiles.
>>>
>>>   It is possible to make another IETF draft 
>>> and add the missing parts there, but it looks 
>>>   -Caller calls with indication of English 
>>> speech reception and English text reception
>>>    Caller prefers speech, but has included 
>>> text for not scaring off friends who prefer 
>>> text. But there is no way to convey this 
>>> preference.
>>>   -Callee has no clue for how to start the 
>>> call, so just taking a chance, the callee 
>>> starts in text, typing "Hi, welcome to my 
>>> service".
>>>   -The caller sees that and feels that it is 
>>> most polite to start in the same modality, so 
>>> the caller thinks it is a bit inconvenient, 
>>> but types: " Hi, I want support for a 
>>> problem. Can we talk?"
>>>   -The callee types: "Oh, yes, let us switch 
>>> to talking" and the the callee says "Ok , 
>>> talking now, what is your problem."
>>>   - The call continues in speech, using text 
>>> just for model numbers, booking numbers URL:s 
>>> etc in this case.
>>>
>>>   This is a quite natural development of a 
>>> call where preference is not indicated from 
>>> the beginning, and it adds inconvenience and 
>>> delay compared to what it could have been if 
>>> there was a way to convey modality preference.
>>>
>>>   I think it is small enough feature to go 
>>> into the humintlang draft and general enough 
>>> to not be pushed to be solved differently for 
>>> each application.
>>>
>>> we heard opposition to that in the meeting, 
>>> so now we are back to the need to add 
>>> something small but important.
>>>
>>>   /Gunnar
>>>
>>>>
>>>>
>>>>
>>>>

-------------- Randomly selected tag: ---------------
Those were my children being slaughtered.
        --Donald Burr, on the death of People Express.

---

From: Gunnar Hellström <[email-masked]>
Date: Thu, 21 Jul 2016 15:38:39 +0200

Den 2016-07-21 kl. 15:09, skrev Randall Gellens:

>>> session is established, the application compares what was accepted 
>>> to the user's preferences across media and languages, determines 
>>> which combination of the accepted media and languages is most 
>>> preferred by the user, and displays that information to the user.
>>  It is not sufficient. We have not defined any way to convey e.g. 
>> that spoken language is preferred over written language.
>
> Conveying the information from the application to the user is out of 
> scope.  Conveying the information from one client to another is not 
> needed.
Why would just this preference not be needed to convey to the other client?
Why do not my examples work to make you understand that without this 
feature, the call has a risk to start with confusion.  ( and it does 
today, because of lack of this feature. )
>
>>
>>  The called party want to start the conversation with a greeting in 
>> the language and the modality that the caller prefers ( if that 
>>  So assume that the caller can use spoken English and written English 
>> and strongly prefers the spoken English.
>>
>>  These capabilities can both be indicated in the offer but without 
>> any preference indication .
>>
> The callee answers with whichever of the requested media and language 
> streams it can support.
And if the one that is least preferred by the caller is selected, part 
of the call or the whole call may be conducted in a modality that is not 
the best one, just because we did not include the possibility to convey 
which one is preferred by the other party.

>
>>
>>  That is the simple case I want a notation for. Just a highest 
>> preference mark to hook on e.g. to the spoken English indication.
>>
>>>>   I guess you mean the whole topic of language negotiation. It is 
>>>> an application level topic about user information and agreement, 
>>>> with some influence on call routing and device selection.
>>>>   If you meant the remaining issues of preference across session, 
>>>> and grouping, it is the same.
>>>>>
>>>>> has been made to limit the complexity of the SDP O/A negotiation 
>>>>> to the bare minimum needed to bring the call up. From there, the 
>>>>> application can add functionality. This approach "optimizes for 
>>>>> the common case",  limits the difficulty in implementing the basic 
>>>> etc and now also language. So, maybe we made the wrong decision to 
>>>> go this way. We could have defined an XML schema for language and 
>>>> modality preferences and conveyed it somehow between the parties. 
>>>> But now we are here with our decision close to WGLC and intend to 
>>>> take this through.
>>>>>
>>>>>   Yes, the application would need to deal with media preferences 
>>>>> but most unified communications applications support multiple 
>>>>> modes and need to handle decisions on media usage already (camera 
>>>>> on/off, mute, etc.) Adding complexity to the SDP parser might 
>>>>> actually make it harder for the application, not easier.
>>>>   The application areas I want to see benefit from this work are 
>>>> wide and do not have any other common specification fora that can 
>>>> add SIP or SDP elements. It is for example 3GPP that convey regular 
>>>> calls with ambition to have interoperability between providers, and 
>>>> it is for example between SIP providers and ESiNets following NENA 
>>>> or EENA specs. They all rely on the ground work done in IETF, for 
>>>>   It is possible to make another IETF draft and add the missing 
>>>> parts there, but it looks unmotivated to break out a small part of 
>>>> the work like that.
>>>>
>>>>   -The caller sees that and feels that it is most polite to start 
>>>> in the same modality, so the caller thinks it is a bit 
>>>> inconvenient, but types: " Hi, I want support for a problem. Can we 
>>>> talk?"
>>>>   -The callee types: "Oh, yes, let us switch to talking" and the 
>>>> the callee says "Ok , talking now, what is your problem."
>>>>   - The call continues in speech, using text just for model 
>>>> numbers, booking numbers URL:s etc in this case.
>>>>
>>>> not indicated from the beginning, and it adds inconvenience and 
>>>> delay compared to what it could have been if there was a way to 
>>>> convey modality preference.
>>>>
>>>>   I think it is small enough feature to go into the humintlang 
>>>> draft and general enough to not be pushed to be solved differently 
>>>> for each application.
>>>>
>>>>   A thought of mine was that the asterisk-notation for "do not 
>>>> fail" was not really needed and we could move that notation to 
>>>> point out the most preferred modality. But we heard opposition to 
>>>> that in the meeting, so now we are back to the need to add

---

From: Randall Gellens <[email-masked]>
Date: Thu, 21 Jul 2016 07:34:00 -0700

At 3:38 PM +0200 7/21/16, Gunnar Hellström wrote:

>>>>   You want the application to be able to 
>>>> first know what the user prefers across all 
>>>> media and languages, and second, to be able 
>>>> to match what was negotiated with the other 
>>>> end with what the user wants.  I believe you 
>>>> can do that with what we have now.
>>>>
>>>>   Consider: the application takes into 
>>>> account the user's preferences across media 
>>>> and languages in deciding what to offer. 
>>>> After the session is established, the 
>>>> application compares what was accepted to 
>>>> languages, determines which combination of 
>>>   It is not sufficient. We have not defined 
>>> any way to convey e.g. that spoken language 
>>> is preferred over written language.
>>
>>  Conveying the information from the application 
>> to the user is out of scope.  Conveying the 

Because this preference is needed to be conveyed 
between endpoints, at least in the current 
document; it can be handled by the client. 
Conveying it would perhaps be more efficient 
because it could avoid setting up media streams 
that won't be used, but this is not sufficient 
reason to add complexity to the current document. 
If you want to propose a new draft that does 
convey this, please do.

>  Why do not my examples work to make you 
> understand that without this feature, the call 
> has a risk to start with confusion.  ( and it 
> does today, because of lack of this feature. )

Fundamentally, the call gets set up and the 
channels with media and language are established, 
so it's a success.  How the clients choose to 
convey information to the user to avoid confusion 
is their business.

>>
>>>
>>>   The called party want to start the 
>>> conversation with a greeting in the language 
>>> and the modality that the caller prefers ( if 
>>> that reasonably matches the callee 
>>> capabilities ).
>>>
>>>   These capabilities can both be indicated in 
>>> the offer but without any preference 
>>> indication .
>>>
>>>   That leaves the callee without a clue on how 
>>> to answer to not cause initial confusion.
>>
>  And if the one that is least preferred by the 
> caller is selected, part of the call or the 
> whole call may be conducted in a modality that 
> is not the best one, just because we did not 
> include the possibility to convey which one is 
> preferred by the other party.

The callee will answer the offer with all media 
and languages it can, and the endpoints will know 
what was set up.  How they convey this to the 
user so the user knows what is the most preferred 
modality and language is its business.  I listed 
the steps a client goes through in my previous 
email.

>
>>
>>>
>>>   That is the simple case I want a notation 
>>> for. Just a highest preference mark to hook 
>>> on e.g. to the spoken English indication.
>>>
>>>>>> question is in what layer this 
>>>>>> functionality belongs.
>>>>>    I guess you mean the whole topic of 
>>>>> language negotiation. It is an application 
>>>>> level topic about user information and 
>>>>> agreement, with some influence on call 
>>>>> routing and device selection.
>>>>>>    In several IETF WGs, including CLUE and 
>>>>>> now WEBRTC, the decision has been made to 
>>>>>> limit the complexity of the SDP O/A 
>>>>>> negotiation to the bare minimum needed to 
>>>>>> bring the call up. From there, the 
>>>>>> application can add functionality. This 
>>>>>> approach "optimizes for the common case", 
>>>>>> limits the difficulty in implementing the 
>>>>>> basic required SDP and makes it more 
>>>>>> likely that it will interoperate.
>>>>> AVPF vs AVP, RTCP vs INFO, multiplexing, 
>>>>> ICE etc and now also language. So, maybe we 
>>>>> made the wrong decision to go this way. We 
>>>>> could have defined an XML schema for 
>>>>> language and modality preferences and 
>>>>> conveyed it somehow between the parties. 
>>>>> But now we are here with our decision close 
>>>>> to WGLC and intend to take this through.
>>>>>>
>>>>>>    AFAICT, the basic SDP functionality in 
>>>>>> the draft appears to be enough to enable 
>>>>>> an application to handle media preference 
>>>>>> on its own.
>>>>>>
>>>>> really sort out what it meant by the 
>>>>> limited indications we provide in SDP.
>>>>>
>>>>>> communications applications support 
>>>>>> multiple modes and need to handle 
>>>>>> decisions on media usage already (camera 
>>>>>> on/off, mute, etc.) Adding complexity to 
>>>>>> the SDP parser might actually make it 
>>>>>> harder for the application, not easier.
>>>>>    The application areas I want to see 
>>>>> benefit from this work are wide and do not 
>>>>> have any other common specification fora 
>>>>> that can add SIP or SDP elements. It is for 
>>>>> example 3GPP that convey regular calls with 
>>>>> ambition to have interoperability between 
>>>>> providers, and it is for example between 
>>>>> SIP providers and ESiNets following NENA or 
>>>>> EENA specs. They all rely on the ground 
>>>>> work done in IETF, for selection into their 
>>>>> profiles.
>>>>>
>>>>> and add the missing parts there, but it 
>>>>> looks unmotivated to break out a small part 
>>>>> of the work like that.
>>>>>
>>>>>    -The caller sees that and feels that it 
>>>>> is most polite to start in the same 
>>>>> modality, so the caller thinks it is a bit 
>>>>> inconvenient, but types: " Hi, I want 
>>>>> support for a problem. Can we talk?"
>>>>>    -The callee types: "Oh, yes, let us 
>>>>> switch to talking" and the the callee says 
>>>>> "Ok , talking now, what is your problem."
>>>>>    - The call continues in speech, using 
>>>>> text just for model numbers, booking 
>>>>> numbers URL:s etc in this case.
>>>>>
>>>>> the beginning, and it adds inconvenience 
>>>>> and delay compared to what it could have 
>>>>> been if there was a way to convey modality 
>>>>> preference.
>>>>>
>>>>> into the humintlang draft and general 
>>>>> enough to not be pushed to be solved 
>>>>> differently for each application.
>>>>>
>>>>> really needed and we could move that 
>>>>> notation to point out the most preferred 
>>>>> modality. But we heard opposition to that 
>>>>> in the meeting, so now we are back to the 
>>>>> need to add something small but important.
>>>>>
>>>>>    /Gunnar
>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>

-------------- Randomly selected tag: ---------------
I think we'd get fewer weird bug reports if we stopped selling our
software off planet.

---

From: Gunnar Hellström <[email-masked]>
Date: Thu, 21 Jul 2016 16:53:47 +0200

Den 2016-07-21 kl. 16:34, skrev Randall Gellens:
>>>>>   Consider: the application takes into account the user's 
>>>>> preferences across media and languages in deciding what to offer. 
>>>>> After the session is established, the application compares what 
>>>>> was accepted to the user's preferences across media and languages, 
>>>>> determines which combination of the accepted media and languages 
>>>>> is most preferred by the user, and displays that information to 
>>>>> the user.
>>>  Conveying the information from the application to the user is out 
>>> of scope.  Conveying the information from one client to another is 
>>> not needed.
> Because this preference is needed to be conveyed between endpoints, at 
> least in the current document; it can be handled by the client. 
> Conveying it would perhaps be more efficient because it could avoid 
> setting up media streams that won't be used, but this is not 
> sufficient reason to add complexity to the current document. If you 
> want to propose a new draft that does convey this, please do.
There is no difference between the "most preferred modality" and the 
"most preferred language per media". They both need in most cases be 
conveyed to the user, but we have selected to not talk about that part 
in the draft.
Without conveying them to the user, the user has no clue about what 
language to start using, and the whole purpose of our work is lost.
So why not convey the whole picture to the client, ( and assume that the 
client informs the user.)
> Fundamentally, the call gets set up and the channels with media and 
> language are established, so it's a success.  How the clients choose 
> to convey information to the user to avoid confusion is their business.
The clients do not handle the language, they just negotiate it on behalf 
of the users. Then the users need to know a definite outcome of the 
negotiation so that they can start producing the expected language. We 
just handle the exchange of this info between the clients, but we have 
no success until some other mechanism informs the user so that language 
can start to flow.
>
>
>>>
>>>>
>>>>   The called party want to start the conversation with a greeting 
>>>> in the language and the modality that the caller prefers ( if that 
>>>>   So assume that the caller can use spoken English and written 
>>>> English and strongly prefers the spoken English.
>>>>
>>>>   That leaves the callee without a clue on how to answer to not 
>>>> cause initial confusion.
>>>
>>>  The callee answers with whichever of the requested media and 
>>> language streams it can support.
>>  And if the one that is least preferred by the caller is selected, 
>> part of the call or the whole call may be conducted in a modality 
>> that is not the best one, just because we did not include the 
>> possibility to convey which one is preferred by the other party.
>
> The callee will answer the offer with all media and languages it can, 
> and the endpoints will know what was set up.  How they convey this to 
> the user so the user knows what is the most preferred modality and 
> language is its business.  I listed the steps a client goes through in 
> my previous email.
We need to tell the other client what is the preferred modality.

If you are afraid of increased complexity, I suggest that we scrap the 
required/advisory feature that you anyway say usually should not be 
followed. Then you have the asterisk notation free to point out the most 
preferred modality with.

>>>>>>    I guess you mean the whole topic of language negotiation. It 
>>>>>> is an application level topic about user information and 
>>>>>> agreement, with some influence on call routing and device selection.
>>>>>>    If you meant the remaining issues of preference across 
>>>>>> session, and grouping, it is the same.
>>>>>>>
>>>>>>>    In several IETF WGs, including CLUE and now WEBRTC, the 
>>>>>>> decision has been made to limit the complexity of the SDP O/A 
>>>>>>> negotiation to the bare minimum needed to bring the call up. 
>>>>>>> From there, the application can add functionality. This approach 
>>>>>>> "optimizes for the common case", limits the difficulty in 
>>>>>>> implementing the basic required SDP and makes it more likely 
>>>>>>> that it will interoperate.
>>>>>> negotiate SRTP vs RTP, AVPF vs AVP, RTCP vs INFO, multiplexing, 
>>>>>> ICE etc and now also language. So, maybe we made the wrong 
>>>>>> decision to go this way. We could have defined an XML schema for 
>>>>>> language and modality preferences and conveyed it somehow between 
>>>>>> the parties. But now we are here with our decision close to WGLC 
>>>>>> and intend to take this through.
>>>>>>>
>>>>>>>    AFAICT, the basic SDP functionality in the draft appears to 
>>>>>>> be enough to enable an application to handle media preference on 
>>>>>>> its own.
>>>>>>>
>>>>>>> within a web application using a modified SIP library without 
>>>>>>> any SDP additions beyond what we already have defined.
>>>>>>    Do you mean that we now need to add SIP headers for the 
>>>>>> remaining information to really sort out what it meant by the 
>>>>>>>    Yes, the application would need to deal with media 
>>>>>>> preferences but most unified communications applications support 
>>>>>>> multiple modes and need to handle decisions on media usage 
>>>>>>> already (camera on/off, mute, etc.) Adding complexity to the SDP 
>>>>>>> parser might actually make it harder for the application, not 
>>>>>>> easier.
>>>>>> add SIP or SDP elements. It is for example 3GPP that convey 
>>>>>> regular calls with ambition to have interoperability between 
>>>>>> providers, and it is for example between SIP providers and 
>>>>>> ESiNets following NENA or EENA specs. They all rely on the ground 
>>>>>> work done in IETF, for selection into their profiles.
>>>>>>
>>>>>> parts there, but it looks unmotivated to break out a small part 
>>>>>> of the work like that.
>>>>>>
>>>>>>     Caller prefers speech, but has included text for not scaring 
>>>>>> off friends who prefer text. But there is no way to convey this 
>>>>>> preference.
>>>>>>    -Callee has no clue for how to start the call, so just taking 
>>>>>> a chance, the callee starts in text, typing "Hi, welcome to my 
>>>>>> service".
>>>>>>    -The caller sees that and feels that it is most polite to 
>>>>>> start in the same modality, so the caller thinks it is a bit 
>>>>>> inconvenient, but types: " Hi, I want support for a problem. Can 
>>>>>> we talk?"
>>>>>>    This is a quite natural development of a call where preference 
>>>>>> is not indicated from the beginning, and it adds inconvenience 
>>>>>> and delay compared to what it could have been if there was a way 
>>>>>> to convey modality preference.
>>>>>>
>>>>>> draft and general enough to not be pushed to be solved

---

From: Bernard Aboba <[email-masked]>
Date: Fri, 22 Jul 2016 06:49:38 +0200

On Jul 21, 2016, at 16:34, Randall Gellens <[email-masked]> wrote:
> 
> Conveying it would perhaps be more efficient because it could avoid setting up media streams that won't be used, but this is not sufficient reason to add complexity to the current document. 

[BA] It is not always possible to know ahead of time whether media will be used or not. Perhaps you were not intending to use text but the audio is faulty so you use text to trouble shoot. Perhaps you have a webcam but realize you are not prepared to go on camera so you turn off video. Negotiating all potential media is often the most robust and flexible choice, but of course, renegotiation is possible too if it becomes clear that a particular media type should be removed from the call.