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

[Randall Gellens <[e-mail]>]

Hi Arnoud,

At 3:49 PM -0800 3/1/17, Arnoud van Wijk wrote:

>  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 
> any changes except the proposed rewording
>
>>   "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)"
>  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.

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.


>  On 01/03/2017 14:06, Gunnar Hellström wrote:
>>  Den 2017-03-01 kl. 18:47, skrev Randall Gellens:
>>>  At 8:26 AM +0100 3/1/17, Gunnar Hellström 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.
>>>
>>>  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


-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly selected tag: ---------------
Life is a long lesson in humility.    --James M. Barrie