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

[Gunnar Hellström <[e-mail]>]

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

> 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.
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 
>> <[e-mail] <mailto:[e-mail]>> 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
>> [e-mail] <mailto:[e-mail]>
>> https://www.ietf.org/mailman/listinfo/slim
>
>
>
> _______________________________________________
> SLIM mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/slim

-- 
-----------------------------------------
Gunnar Hellström
Omnitor
[e-mail]
[phone]