Subject: Re: [Slim] I-D Action: draft-ietf-slim-negotiating-human-language-07.txt

From: Brian Rosen <[email-masked]>
Date: Wed, 1 Mar 2017 08:34:11 -0500

I haven’t commented on this thread much, but I agree with Randall.

I am opposed to a protocol document saying anything about human interface.  The answering device may be an automaton, and there could be very good reasons to not tell the human which languages/media are not the least preferred.  

Designing good user interfaces is very hard, the participants on this list are not experts, and we should not offer advice on human factors in our documents.  It is sufficient to transport the information across the wire.

Brian

> On Mar 1, 2017, at 2:26 AM, Gunnar Hellström <[email-masked]> wrote:
> 
> Hi Randall, 
> Den 2017-03-01 kl. 02:08, skrev Randall Gellens:
>> Hi Gunnar, 
>> 
>> I'm starting a new message to cut out the huge amount of quoting. 
>> 
>> Your proposal is that text be added that advises the calling client to place an asterisk on the least-preferred language/media, and advises the answering client to indicate to the answering human which language/media is not the least preferred (did not have an asterisk in the offer), is that accurate? 
> Yes, with slight rewording to:
> "text that advises the offering client to place an asterisk on the least-preferred language/media indications, and advises the answering client to indicate to the answering human which language/media are not the least preferred (did not have an asterisk in the offer)"
> 
> The inclusion of the "indications" is just to assure that it is clear that it does not need to be just one indication that gets the asterisk .
> The last part sounds awkward, but matches technically what the lack of an asterisk means. I inherited the inverted logic for the asterisk from its already defined non-denial meaning. 
> If you are considering wording for the draft, I suggest that you straighten the logic to say "which language/media are most preferred (did not have an asterisk in the offer)"
> 
> It does also not need to be an "answering human" that gets this indication and makes use of it for guidance on how to answer the call. It can just as well be e.g. a multi-modal answering machine or some other application interacting with human language. I am not sure if "answering party" is more appropriate and can be considered including such automata.  
> 
> Thanks,
> Gunnar
> 
> 
> _______________________________________________
> SLIM mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/slim

---

From: Gunnar Hellström <[email-masked]>
Date: Wed, 1 Mar 2017 17:05:20 +0100

Den 2017-03-01 kl. 14:34, skrev Brian Rosen:

> I am opposed to a protocol document saying anything about human 
> interface.  The answering device may be an automaton, and there could 
> be very good reasons to not tell the human which languages/media are 
> not the least preferred.
Yes, we discussed this before and limited us to expressions like the one 
in chapter 1. " Both sides
    should be aware of which language was negotiated. "

That is as much as we need to say. The need is equal for the languages, 
the modalities and the preferences.
If the answering instance has registered capability in spoken English, 
French or Greek, and only Greek matches what the caller has indicated, 
the answering instance need to become aware of that so that the call can 
be started in the proper way in spoken Greek.
Also if the caller indicates a preference for receiving written English, 
or at lower preference spoken English, and the answering instance is 
capable of both, the answering instance need to become aware of the 
preferenceso that the call can be started in the way that results in the 
most successful start in written English.

My minimal wording proposal in issue 12 was:

"The asterisk should be attached to attributes with languages of lower
   preference to be matched if such difference can be specified. Thereby
   the location of the asterisk can be used to support the decision on
   which languages to use in the call."

This is not user interface specification, and likely as far as we should 
go in order to not specify user interface more for this preference 
indication than we do for the other language and preference indicators.

I wonder what Randall had in mind by the recent question about what my 
words meant.

Regards
Gunnar

>
> Designing good user interfaces is very hard, the participants on this 
> list are not experts, and we should not offer advice on human factors 
> in our documents.  It is sufficient to transport the information 
> across the wire.
>
> Brian
>
>> On Mar 1, 2017, at 2:26 AM, Gunnar Hellström 
>> <[email-masked] <mailto:[email-masked]>> wrote:
>>
>> Hi Randall,
>>> Your proposal is that text be added that advises the calling client 
>>> to place an asterisk on the least-preferred language/media, and 
>>> advises the answering client to indicate to the answering human 
>>> which language/media is not the least preferred (did not have an 
>>> asterisk in the offer), is that accurate?
>> "text that advises the *offering* client to place an asterisk on the 
>> least-preferred language/media *indications*, and advises the 
>> answering client to indicate to the answering human which 
>> language/media are not the least preferred (did not have an asterisk 
>> in the offer)"
>>
>> The inclusion of the "indications" is just to assure that it is clear 
>> that it does not need to be just one indication that gets the asterisk .
>> The last part sounds awkward, but matches technically what the lack 
>> of an asterisk means. I inherited the inverted logic for the asterisk 
>> from its already defined non-denial meaning.
>> If you are considering wording for the draft, I suggest that you 
>> straighten the logic to say "*which language/media are most preferred 
>> (did not have an asterisk in the offer)*"
>>
>> It does also not need to be an "answering human" that gets this 
>> indication and makes use of it for guidance on how to answer the 
>> call. It can just as well be e.g. a multi-modal answering machine or 
>> some other application interacting with human language. I am not sure 
>> if "*answering party*" is more appropriate and can be considered 
>> including such automata.
>>
>> Thanks,
>> Gunnar
>>
>>
>> [email-masked] <mailto:[email-masked]>

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

---

From: Randall Gellens <[email-masked]>
Date: Wed, 1 Mar 2017 09:47:01 -0800

At 8:26 AM +0100 3/1/17, Gunnar Hellström wrote:

>>  Your proposal is that text be added that 
>> advises the calling client to place an 
>> asterisk on the least-preferred 
>> language/media, and advises the answering 
>> client to indicate to the answering human 
>> which language/media is not the least 
>> preferred (did not have an asterisk in the 
>> offer), is that accurate?
>>
>  "text that advises the offering client to place 
> an asterisk on the least-preferred 
> language/media indications, and advises the 
> answering client to indicate to the answering 
> human which language/media are not the least 
> preferred (did not have an asterisk in the 
> offer)"
>
>  The inclusion of the "indications" is just to 
> assure that it is clear that it does not need 
> to be just one indication that gets the 
> asterisk .
>  The last part sounds awkward, but matches 
> technically what the lack of an asterisk means. 
> I inherited the inverted logic for the asterisk 
>  If you are considering wording for the draft, I 
> suggest that you straighten the logic to say 
> "which language/media are most preferred (did 
> not have an asterisk in the offer)"
>
>  It does also not need to be an "answering 
> human" that gets this indication and makes use 
> of it for guidance on how to answer the call. 
> It can just as well be e.g. a multi-modal 
> answering machine or some other application 
> interacting with human language. I am not sure 
> if "answering party" is more appropriate and 
> can be considered including such automata.

Hi Gunnar,

Thanks for clarifying, I think I understand your 
proposal in detail now.  After thinking it over, 
I still think this would be better done in a new 
draft, because (a) it is advice on a way of using 
the mechanism to convey additional information; 
(b) it would be good for the group to discuss the 
proposal and work through various cases (e.g., 
what if the offering client is not going to 
include an asterisk, what if there is more than 
one most-preferred language); and (c) it would be 
good for the group to decide if this meets your 
need.

A new draft, especially one that will be either 
Informational or BCP, can be done fairly quickly. 
It could be quite short, perhaps only a page or 
two of real text plus the boilerplate text.  I am 
happy to help with it.

-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly selected tag: ---------------
Build a system that even a fool can use, and only a fool will
want to use it.

---

From: Randall Gellens <[email-masked]>
Date: Wed, 1 Mar 2017 09:50:36 -0800

At 8:34 AM -0500 3/1/17, Brian Rosen wrote:

>  I haven't commented on this thread much, but I agree with Randall.
>
>  I am opposed to a protocol document saying 
> anything about human interface.  The answering 
> device may be an automaton, and there could be 
> very good reasons to not tell the human which 
> languages/media are not the least preferred.
>
>  Designing good user interfaces is very hard, 
> the participants on this list are not experts, 
> and we should not offer advice on human factors 
> in our documents.  It is sufficient to 
> transport the information across the wire.

Hi Brian,

Gunnar's proposal is now a means of conveying 
additional information that can be used by the UI 
but does not discuss UI.  However, I think this 
is better done in a new Informational (or maybe 
BCP) draft that offers advice to implementers and 
can discuss the various use cases.

>> <<mailto:[email-masked]>[email-masked]> 
>> wrote:
>>
>>  Hi Randall,
>>
>>  "text that advises the offering client to 
>> place an asterisk on the least-preferred 
>> technically what the lack of an asterisk 
>> means. I inherited the inverted logic for the 
>> asterisk from its already defined non-denial 
>> meaning.
>>  If you are considering wording for the draft, 
>> I suggest that you straighten the logic to say 
>>  <mailto:[email-masked]>[email-masked]

-------------- Randomly selected tag: ---------------
There are two kinds of lawyers, those who know the law and those who
know the judge.

---

From: Gunnar Hellström <[email-masked]>
Date: Wed, 1 Mar 2017 23:06:38 +0100

Den 2017-03-01 kl. 18:47, skrev Randall Gellens:
>>  "text that advises the offering client to place an asterisk on the 
>> least-preferred language/media indications, and advises the answering 
>> client to indicate to the answering human which language/media are 
>> not the least preferred (did not have an asterisk in the offer)"
>>
>>  The inclusion of the "indications" is just to assure that it is 
>> clear that it does not need to be just one indication that gets the 
>> asterisk .
>> straighten the logic to say "which language/media are most preferred 
>> (did not have an asterisk in the offer)"
>>
>> if "answering party" is more appropriate and can be considered 
>> including such automata.
>
> Hi Gunnar,
>
> Thanks for clarifying, I think I understand your proposal in detail 
> now.  After thinking it over, I still think this would be better done 
> in a new draft, because (a) it is advice on a way of using the 
> mechanism to convey additional information; (b) it would be good for 
> the group to discuss the proposal and work through various cases 
> (e.g., what if the offering client is not going to include an 
> asterisk, what if there is more than one most-preferred language); and 
> (c) it would be good for the group to decide if this meets your need.
Randall,
Good that you understand it now.
I realize that this kind of added rules for an already existing 
parameter could be specified in an additional draft. Especially since it 
has no impact on the current meaning of the asterisk.
I still think it is best to add the few words needed now. The preference 
indication is so severely unbalanced without it, in that only preference 
between languages in the same modality can be specified. I am afraid 
that it can be seen as a discrimination against those who would need to 
specify preference between different modalities in order to tget equal 
opportunities to get smoothly performed calls through, but cannot.

You are right that there are situations that will not be explained if we 
accept my little extra sentence or something similar.
That is true also for the currently specified indications. We have said 
that we nearly only specify the indications and not how the negotiation 
shall be performed. It can be a topic for a BCP to advice on how the 
negotiation could be performed both with the currently specified 
language and in-media preferences and with the additional preference 
between media. We could discuss e.g. the case when two same spoken 
languages are specified but with the opposite preference order by the 
offeror and answering party. A decision must be taken, because the 
protocol says that oly one language per media and direction may be 
indicated in the answer, and also that the answering instance need to 
become aware of which language it shall produce.
I do not say that we need to resolve this case. It can be discussed in a 
BCP, and indicated that additional policy may be applied for solving 
that kind of undefined cases.

Similarily, there will be situations with the additional use of the 
asterisk that will be good to provide extra information for in a BCP. 
The preference indication is very rough, with only two levels. So there 
wil of course be situations when the users will wonder how to set their 
profile, and cases when the negotiation will be hard to assign a well 
motivated result. But we have said that we want to have the 
specification on this rough level.

The two cases that you bring up can have this treatment:

1. If the calling user want to get the call denied if no languages 
match, then the user must make a decision if that preference is more 
important to specify than the preference between modalities. In order to 
keep complexity low, I do not think that we should specify how to code 
both preferences.

2. If there are more than one most-preferred language. I understand this 
as for example a user is equally happy to use French sign language as 
spoken French, and can also, but on lower preference level write French 
text. That would be indicated by an asterisk on the French text, and the 
answering party having all these three capabilities may omit the French 
text from the answer but keep the others. Then the answering user select 
one of the spoken French and French Sign Language for its start of the 
call, knowing that the caller will be approximately equally happy with 
the call in both these cases.   Was that the case you thought about for 
the second case?

I understand that you wanted to check more than these two cases and 
discuss them with the WG, so the above is just a start. We can do more 
cases if you want, but I do not think we need any lengthy discussion 
that would delay the current draft.

>
>
> A new draft, especially one that will be either Informational or BCP, 
> can be done fairly quickly. It could be quite short, perhaps only a 
> page or two of real text plus the boilerplate text.  I am happy to 
> help with it.
>
Tanks,

Gunnar

---

From: Arnoud van Wijk <[email-masked]>
Date: Wed, 1 Mar 2017 15:49:01 -0800

Hi all,

I have been reading the draft and trying to follow the discussions so far.

Randall, this is a very interesting draft and very useful to indicate 
the different language preferences in a call.

The first thing that I noticed is that I would not be able to select my 
language preference to e.g. send spoken English and if not possible then 
to send English in RTT. At the same time I do have the preference to 
receive RTT in English and if not possible then to receive the video so 
I can (try to )lipread the other person.

So, the ability to set a language preference between different 
modalities instead of only language preferences within one modality is 
quite essential for many users who have a limited or no ability to use a 
certain modality.

For example a user prefers to receive ASL but if that is not possible 
then receive RTT is fine. Sending ASL and if not possible send RTT. But 
skip audio.

So, how can we indicate the language preferences in sending and 
receiving modalities/different media instead of  only the selection of 
language within one modality/media?

I read Gunnar's proposal to use the asterisk  to indicate the least 
preferred media. I think it is an excellent idea since it won't require 
any changes except the proposed rewording

> client to indicate to the answering human which language/media are not 
> the least preferred (did not have an asterisk in the offer)" 
and then as mentioned by Gunnar a BCP could expand on all the use cases. 
And how to answer such offers as a relay center, emergency center or any 
other system that is able to invoke a relay operator in case the 
preferred language modality/media is not possible.

That are my observations and insights so far.

cheers

Arnoud

On 01/03/2017 14:06, Gunnar Hellström wrote:
>>>>  Your proposal is that text be added that advises the calling 
>>>> client to place an asterisk on the least-preferred language/media, 
>>>> and advises the answering client to indicate to the answering human 
>>> least-preferred language/media indications, and advises the 
>>> of an asterisk means. I inherited the inverted logic for the 
>>> asterisk from its already defined non-denial meaning.
>>> some other application interacting with human language. I am not 
>>> sure if "answering party" is more appropriate and can be considered 
>>> including such automata.
>>
>> Hi Gunnar,
>>
>> asterisk, what if there is more than one most-preferred language); 
>> and (c) it would be good for the group to decide if this meets your 
>> need.
> Randall,
> parameter could be specified in an additional draft. Especially since 
> it has no impact on the current meaning of the asterisk.
> I still think it is best to add the few words needed now. The 
> preference indication is so severely unbalanced without it, in that 
> only preference between languages in the same modality can be 
> specified. I am afraid that it can be seen as a discrimination against 
> those who would need to specify preference between different 
> modalities in order to tget equal opportunities to get smoothly 
> performed calls through, but cannot.
>
> You are right that there are situations that will not be explained if 
> we accept my little extra sentence or something similar.
> That is true also for the currently specified indications. We have 
> said that we nearly only specify the indications and not how the 
> negotiation shall be performed. It can be a topic for a BCP to advice 
> on how the negotiation could be performed both with the currently 
> specified language and in-media preferences and with the additional 
> preference between media. We could discuss e.g. the case when two same 
> spoken languages are specified but with the opposite preference order 
> by the offeror and answering party. A decision must be taken, because 
> the protocol says that oly one language per media and direction may be 
> I do not say that we need to resolve this case. It can be discussed in 
> a BCP, and indicated that additional policy may be applied for solving 
> The preference indication is very rough, with only two levels. So 
> there wil of course be situations when the users will wonder how to 
> set their profile, and cases when the negotiation will be hard to 
> assign a well motivated result. But we have said that we want to have 
> the specification on this rough level.
>
> important to specify than the preference between modalities. In order 
> to keep complexity low, I do not think that we should specify how to 
> code both preferences.
>
> 2. If there are more than one most-preferred language. I understand 
> this as for example a user is equally happy to use French sign 
> language as spoken French, and can also, but on lower preference level 
> write French text. That would be indicated by an asterisk on the 
> French text, and the answering party having all these three 
> capabilities may omit the French text from the answer but keep the 
> others. Then the answering user select one of the spoken French and 
> French Sign Language for its start of the call, knowing that the 
> caller will be approximately equally happy with the call in both these 
> cases.   Was that the case you thought about for the second case?
>

---

From: Randall Gellens <[email-masked]>
Date: Wed, 1 Mar 2017 18:18:57 -0800

Hi Arnoud,

>  I have been reading the draft and trying to follow the discussions so far.

Please check version -08, the most current.

>  Randall, this is a very interesting draft and 
> very useful to indicate the different language 
> preferences in a call.
>
>  The first thing that I noticed is that I would 
> not be able to select my language preference to 
> e.g. send spoken English and if not possible 
> then to send English in RTT. At the same time I 
> do have the preference to receive RTT in 
> English and if not possible then to receive the 
> video so I can (try to )lipread the other 
> person.
>
>  So, the ability to set a language preference 
> between different modalities instead of only 
> language preferences within one modality is 
> quite essential for many users who have a 
> limited or no ability to use a certain modality.
>
>  For example a user prefers to receive ASL but 
> if that is not possible then receive RTT is 
> fine. Sending ASL and if not possible send RTT. 
> But skip audio.
>
>  So, how can we indicate the language 
> preferences in sending and receiving 
> modalities/different media instead of  only the 
> selection of language within one modality/media?

This has been discussed extensively within the 
SLIM WG, and I do not wish to replay the entire 
debate.  The short answer is that you do not 
indicate preferences between media, you request 
all media/languages you are comfortable using, 
and the callee accepts those it supports.  The 
draft has now closed IETF last call, so it is 
rather far along to reopen an issue that has 
already had extensive debate.  Obviously, if you 
feel the group has missed something that was not 
included in the previous discussions, please 
point this out.

>  I read Gunnar's proposal to use the asterisk 
> to indicate the least preferred media. I think 
> it is an excellent idea since it won't require 
>  and then as mentioned by Gunnar a BCP could 
> expand on all the use cases. And how to answer 
> such offers as a relay center, emergency center 
> or any other system that is able to invoke a 
> relay operator in case the preferred language 
> modality/media is not possible.
>

Thank you, I appreciate it.  Your observations 
will be more meaningful after you have read 
through the list archive for the various emails 
discussing language preference; if after having 
done so you feel that the group has missed 
something, please let us know.

>>>> answering client to indicate to the 
>>>> answering human which language/media are not 
>>>>   The inclusion of the "indications" is just 
>>>> to assure that it is clear that it does not 
>>>> need to be just one indication that gets the 
>>>> asterisk .
>>>> means. I inherited the inverted logic for 
>>>> the asterisk from its already defined 
>>>> non-denial meaning.
>>>>   If you are considering wording for the 
>>>> draft, I suggest that you straighten the 
>>>> logic to say "which language/media are most 
>>>> human" that gets this indication and makes 
>>>> use of it for guidance on how to answer the 
>>>> call. It can just as well be e.g. a 
>>>> multi-modal answering machine or some other 
>>>> application interacting with human language. 
>>>> I am not sure if "answering party" is more 
>>>> appropriate and can be considered including 
>>>> such automata.
>>>
>>>  Hi Gunnar,
>>>
>>>  Thanks for clarifying, I think I understand 
>>> your proposal in detail now.  After thinking 
>>> it over, I still think this would be better 
>>> done in a new draft, because (a) it is advice 
>>> on a way of using the mechanism to convey 
>>> additional information; (b) it would be good 
>>> for the group to discuss the proposal and 
>>> work through various cases (e.g., what if the 
>>> offering client is not going to include an 
>>> asterisk, what if there is more than one 
>>> most-preferred language); and (c) it would be 
>>> good for the group to decide if this meets 
>>> your need.
>>  Randall,
>>  I realize that this kind of added rules for an 
>> already existing parameter could be specified 
>> in an additional draft. Especially since it 
>>  I still think it is best to add the few words 
>> needed now. The preference indication is so 
>> severely unbalanced without it, in that only 
>> preference between languages in the same 
>> modality can be specified. I am afraid that it 
>> can be seen as a discrimination against those 
>> who would need to specify preference between 
>> different modalities in order to tget equal 
>>  You are right that there are situations that 
>> will not be explained if we accept my little 
>> extra sentence or something similar.
>>  That is true also for the currently specified 
>> indications. We have said that we nearly only 
>> specify the indications and not how the 
>> negotiation shall be performed. It can be a 
>> topic for a BCP to advice on how the 
>> negotiation could be performed both with the 
>> currently specified language and in-media 
>> preferences and with the additional preference 
>> between media. We could discuss e.g. the case 
>> when two same spoken languages are specified 
>> but with the opposite preference order by the 
>> offeror and answering party. A decision must 
>> be taken, because the protocol says that oly 
>> one language per media and direction may be 
>> indicated in the answer, and also that the 
>> answering instance need to become aware of 
>> which language it shall produce.
>>  I do not say that we need to resolve this 
>> case. It can be discussed in a BCP, and 
>> indicated that additional policy may be 
>> applied for solving that kind of undefined 
>> cases.
>>
>>  Similarily, there will be situations with the 
>> additional use of the asterisk that will be 
>> good to provide extra information for in a 
>> BCP. The preference indication is very rough, 
>> with only two levels. So there wil of course 
>> be situations when the users will wonder how 
>> to set their profile, and cases when the 
>> negotiation will be hard to assign a well 
>> motivated result. But we have said that we 
>> want to have the specification on this rough 
>> level.
>>
>>  1. If the calling user want to get the call 
>> denied if no languages match, then the user 
>> must make a decision if that preference is 
>> more important to specify than the preference 
>> between modalities. In order to keep 
>> complexity low, I do not think that we should 
>> specify how to code both preferences.
>>
>>  2. If there are more than one most-preferred 
>> language. I understand this as for example a 
>> user is equally happy to use French sign 
>> language as spoken French, and can also, but 
>> on lower preference level write French text. 
>> That would be indicated by an asterisk on the 
>> French text, and the answering party having 
>> all these three capabilities may omit the 
>> French text from the answer but keep the 
>> others. Then the answering user select one of 
>> the spoken French and French Sign Language for 
>> its start of the call, knowing that the caller 
>> will be approximately equally happy with the 
>> call in both these cases.   Was that the case 
>> you thought about for the second case?
>>
>>  I understand that you wanted to check more 
>> than these two cases and discuss them with the 
>> WG, so the above is just a start. We can do 
>> more cases if you want, but I do not think we 
>> need any lengthy discussion that would delay 
>> the current draft.
>>
>>>
>>>
>>>  A new draft, especially one that will be 
>>> either Informational or BCP, can be done 
>>> fairly quickly. It could be quite short, 
>>> perhaps only a page or two of real text plus 
>>> the boilerplate text.  I am happy to help 
>>> with it.
>>>
>>  Tanks,
>>
>>  Gunnar

-------------- Randomly selected tag: ---------------
Life is a long lesson in humility.    --James M. Barrie

---

From: Randall Gellens <[email-masked]>
Date: Wed, 1 Mar 2017 18:21:02 -0800

Hi Gunnar,

At 11:06 PM +0100 3/1/17, Gunnar Hellström wrote:

>> for the group to discuss the proposal and work 
>> through various cases (e.g., what if the 
> in an additional draft. Especially since it has 
> no impact on the current meaning of the 
> asterisk.
> offeror and answering party. A decision must be 
> taken, because the protocol says that oly one 
> language per media and direction may be 
>  I do not say that we need to resolve this case. 
> It can be discussed in a BCP, and indicated 
> that additional policy may be applied for 
> solving that kind of undefined cases.
>
> good to provide extra information for in a BCP. 
> The preference indication is very rough, with 
> only two levels. So there wil of course be 
> situations when the users will wonder how to 
> set their profile, and cases when the 
> motivated result. But we have said that we want 
> to have the specification on this rough level.
>
> must make a decision if that preference is more 
> important to specify than the preference 
> between modalities. In order to keep complexity 
> low, I do not think that we should specify how 
> to code both preferences.
>
> language as spoken French, and can also, but on 
> lower preference level write French text. That 
> would be indicated by an asterisk on the French 
> text, and the answering party having all these 
> three capabilities may omit the French text 
> from the answer but keep the others. Then the 
> answering user select one of the spoken French 
> and French Sign Language for its start of the 
> call, knowing that the caller will be 
> approximately equally happy with the call in 
> both these cases.   Was that the case you 
> thought about for the second case?
>
>  I understand that you wanted to check more than 
> these two cases and discuss them with the WG, 
> so the above is just a start. We can do more 
> cases if you want, but I do not think we need 
> any lengthy discussion that would delay the 
> current draft.
>
>>
>>
>> the boilerplate text.  I am happy to help with 
>> it.

I see your point, however, my view is that this 
is best covered in a separate draft.  As I said 
above, the draft can be completed very quickly if 
it is Informational (or even BCP), clear and not 
controversial.  I am happy to help.

-------------- Randomly selected tag: ---------------
    The highlight of the annual Computer Bowl occurred when Bill Gates,
who was a judge, posed the following question to the contestants:
    "What contest, held via Usenet, is dedicated to examples of weird,
obscure, bizarre, and really bad programming?"
    After a moment of silence, Jean-Louis Gassee (ex-honcho at Apple)
hit his buzzer and answered "Windows."
                                          --Recounted by Adam C. Engst

---

From: Natasha Rooney <[email-masked]>
Date: Tue, 7 Mar 2017 14:18:06 +0000

Hi all,

I’ve been catching up on the discussions after a long business trip - so many apologies for the late response.

The idea of working on Gunnar’s suggestions within a separate draft seems like a good idea; it doesn’t delay the current draft’s progress nor does it ignore a good proposal. It seems people are ok with this decision, so let’s do that.

Gunnar - if you want to make a start on this that would be fab; Randall has offered support for this so we can rely on him for text and review.

Natasha

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

On 2 Mar 2017, at 02:21, Randall Gellens <[email-masked]<mailto:[email-masked]>> wrote:

Hi Gunnar,

 Hi Randall,

 Hi Gunnar,

Hi Gunnar,

Thanks for clarifying, I think I understand your proposal in detail now.  After thinking it over, I still think this would be better done in a new draft, because (a) it is advice on a way of using the mechanism to convey additional information; (b) it would be good for the group to discuss the proposal and work through various cases (e.g., what if the offering client is not going to include an asterisk, what if there is more than one most-preferred language); and (c) it would be good for the group to decide if this meets your need.
Randall,
Good that you understand it now.
I realize that this kind of added rules for an already existing parameter could be specified in an additional draft. Especially since it has no impact on the current meaning of the asterisk.
I still think it is best to add the few words needed now. The preference indication is so severely unbalanced without it, in that only preference between languages in the same modality can be specified. I am afraid that it can be seen as a discrimination against those who would need to specify preference between different modalities in order to tget equal opportunities to get smoothly performed calls through, but cannot.

You are right that there are situations that will not be explained if we accept my little extra sentence or something similar.
That is true also for the currently specified indications. We have said that we nearly only specify the indications and not how the negotiation shall be performed. It can be a topic for a BCP to advice on how the negotiation could be performed both with the currently specified language and in-media preferences and with the additional preference between media. We could discuss e.g. the case when two same spoken languages are specified but with the opposite preference order by the offeror and answering party. A decision must be taken, because the protocol says that oly one language per media and direction may be indicated in the answer, and also that the answering instance need to become aware of which language it shall produce.
I do not say that we need to resolve this case. It can be discussed in a BCP, and indicated that additional policy may be applied for solving that kind of undefined cases.

Similarily, there will be situations with the additional use of the asterisk that will be good to provide extra information for in a BCP. The preference indication is very rough, with only two levels. So there wil of course be situations when the users will wonder how to set their profile, and cases when the negotiation will be hard to assign a well motivated result. But we have said that we want to have the specification on this rough level.

1. If the calling user want to get the call denied if no languages match, then the user must make a decision if that preference is more important to specify than the preference between modalities. In order to keep complexity low, I do not think that we should specify how to code both preferences.

2. If there are more than one most-preferred language. I understand this as for example a user is equally happy to use French sign language as spoken French, and can also, but on lower preference level write French text. That would be indicated by an asterisk on the French text, and the answering party having all these three capabilities may omit the French text from the answer but keep the others. Then the answering user select one of the spoken French and French Sign Language for its start of the call, knowing that the caller will be approximately equally happy with the call in both these cases.   Was that the case you thought about for the second case?

I understand that you wanted to check more than these two cases and discuss them with the WG, so the above is just a start. We can do more cases if you want, but I do not think we need any lengthy discussion that would delay the current draft.

A new draft, especially one that will be either Informational or BCP, can be done fairly quickly. It could be quite short, perhaps only a page or two of real text plus the boilerplate text.  I am happy to help with it.

I see your point, however, my view is that this is best covered in a separate draft.  As I said above, the draft can be completed very quickly if it is Informational (or even BCP), clear and not controversial.  I am happy to help.

-------------- Randomly selected tag: ---------------

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: Tue, 7 Mar 2017 21:44:41 +0100

Hi,

Den 2017-03-07 kl. 15:18, skrev Natasha Rooney:
> The idea of working on Gunnar’s suggestions within a separate draft 
> seems like a good idea; it doesn’t delay the current draft’s progress 
> nor does it ignore a good proposal. It seems people are ok with this 
> decision, so let’s do that.
>
> Gunnar - if you want to make a start on this that would be fab; 
> Randall has offered support for this so we can rely on him for text 
> and review.
Well, I am trying to convince you that we should do the opposite. To 
include a lightweight solution on the need for preference indication 
between modalities.
Because without it the draft is unbalanced and does not meet its own 
declared requirements and is discriminating against persons with 
disabilities. And the simple solution also motivates why we have the 
asterisk as a parameter on media level, while with the current 
functional description it should rather be defined as an attribute on 
session level.

But Bernard has during LC requested a solution also on the indication of 
a need for captions, and that is not as easily done as an extension on 
the current hlang coding. If you read my summary of the LC comments and 
resolutions on March 4, you may have seen in item n) by the end three 
different principles for solution of both the preference between 
modalities and the simultaneity indication needed for captions.  One of 
the three solution principles is based on that we accept Dale's proposal 
to change coding of the attribute to be similar to the Accept-Language 
syntax.  That is probably the cleanest solution. So even if we let the 
current draft go to publication without these two functionalities, we 
need to select a principle for the extensions and make sure that the 
draft is in line with the extensions.

We should have a discussion on the three solution principles and decide 
which one to use.

Regards
/Gunnar

>
> Natasha
>
> Natasha Rooney | Internet Engineering Director | Internet and Web Team 
> | Technology | GSMA | [email-masked] <mailto:[email-masked]> | +44 
> (0) 7730 219 765 | @thisNatasha | Skype: [email-masked] 
> <mailto:[email-masked]>
>
>> On 2 Mar 2017, at 02:21, Randall Gellens <[email-masked] 
>> <mailto:[email-masked]>> wrote:
>>
>> Hi Gunnar,
>>
>>>>>> client to place an asterisk on the least-preferred 
>>>>>> language/media, and advises the answering client to indicate to 
>>>>>> the answering human which language/media is not the least 
>>>>>> preferred (did not have an asterisk in the offer), is that accurate?
>>>>>>
>>>>>  "text that advises the offering client to place an asterisk on 
>>>>> the least-preferred language/media indications, and advises the 
>>>>> language/media are not the least preferred (did not have an 
>>>>> asterisk in the offer)"
>>>>>
>>>>> clear that it does not need to be just one indication that gets 
>>>>> the asterisk .
>>>>>  The last part sounds awkward, but matches technically what the 
>>>>> lack of an asterisk means. I inherited the inverted logic for the 
>>>>> straighten the logic to say "which language/media are most 
>>>>> preferred (did not have an asterisk in the offer)"
>>>>>
>>>>> call. It can just as well be e.g. a multi-modal answering machine 
>>>>> or some other application interacting with human language. I am 
>>>>> not sure if "answering party" is more appropriate and can be 
>>>>> considered including such automata.
>>>>
>>>> Hi Gunnar,
>>>>
>>>> now.  After thinking it over, I still think this would be better 
>>>> done in a new draft, because (a) it is advice on a way of using the 
>>>> mechanism to convey additional information; (b) it would be good 
>>>> for the group to discuss the proposal and work through various 
>>>> cases (e.g., what if the offering client is not going to include an 
>>> parameter could be specified in an additional draft. Especially 
>>> since it has no impact on the current meaning of the asterisk.
>>> specified. I am afraid that it can be seen as a discrimination 
>>> against those who would need to specify preference between different 
>>> You are right that there are situations that will not be explained 
>>> if we accept my little extra sentence or something similar.
>>> negotiation shall be performed. It can be a topic for a BCP to 
>>> advice on how the negotiation could be performed both with the 
>>> currently specified language and in-media preferences and with the 
>>> additional preference between media. We could discuss e.g. the case 
>>> when two same spoken languages are specified but with the opposite 
>>> preference order by the offeror and answering party. A decision must 
>>> be taken, because the protocol says that oly one language per media 
>>> and direction may be indicated in the answer, and also that the 
>>> answering instance need to become aware of which language it shall 
>>> produce.
>>> I do not say that we need to resolve this case. It can be discussed 
>>> in a BCP, and indicated that additional policy may be applied for 
>>> asterisk that will be good to provide extra information for in a 
>>> BCP. The preference indication is very rough, with only two levels. 
>>> So there wil of course be situations when the users will wonder how 
>>> to set their profile, and cases when the negotiation will be hard to 
>>> assign a well motivated result. But we have said that we want to 
>>> have the specification on this rough level.
>>>
>>> important to specify than the preference between modalities. In 
>>> order to keep complexity low, I do not think that we should specify 
>>> how to code both preferences.
>>>
>>> language as spoken French, and can also, but on lower preference 
>>> level write French text. That would be indicated by an asterisk on 
>>> the French text, and the answering party having all these three 
>>> caller will be approximately equally happy with the call in both 
>>> these cases.   Was that the case you thought about for the second case?
>>>
>>> discuss them with the WG, so the above is just a start. We can do 
>>> more cases if you want, but I do not think we need any lengthy 
>>> discussion that would delay the current draft.
>>>
>>>>
>>>>
>>>> A new draft, especially one that will be either Informational or 
>>>> BCP, can be done fairly quickly. It could be quite short, perhaps 
>>>> only a page or two of real text plus the boilerplate text.  I am 
>>>> happy to help with it.
>>
>> I see your point, however, my view is that this is best covered in a 
>> separate draft.  As I said above, the draft can be completed very 
>> quickly if it is Informational (or even BCP), clear and not 
> 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.
>