Re: [Slim] Eric Rescorla's No Objection on draft-ietf-slim-negotiating-human-language-19: (with COMMENT)

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

Den 2018-01-12 kl. 00:21, skrev Randall Gellens:
> At 11:43 PM +0100 1/11/18, Gunnar Hellström wrote:
>
>>  Den 2018-01-11 kl. 23:12, skrev Randall Gellens:
>>>  At 4:02 PM -0500 1/11/18, Paul Kyzivat wrote:
>>>
>>>>   On 1/10/18 3:02 PM, Gunnar Hellström wrote:
>>>>>   Den 2018-01-10 kl. 16:51, skrev Paul Kyzivat:
>>>>>>   Gunnar,
>>>>>>
>>>>>>   I would like to understand your thinking about how the language 
>>>>>> indications will be used. Your comments below suggest to me that 
>>>>>> you are assuming that they will be exposed to the end users 
>>>>>> through a UI. If that is not the case then order of preference of 
>>>>>> one language over another won't have any influence over how the 
>>>>>> session proceeds.
>>>>>   Yes, it is in most applications the human end users who are 
>>>>> expected to produce and understand the negotiated language(s). 
>>>>> Therefore the final result of the negotiation must be presented to 
>>>>> the users. (or, in less common automatic conversation cases, fed 
>>>>> to an automata for generating the agreed language).
>>>>>   We say that this must happen, but it is not the task of the 
>>>>> draft to say how.
>>>>>
>>>>>   Examples:
>>>>>
>>>>>   If it is a regular conversational call application, it could 
>>>>> present what the application regards to be the best match on the 
>>>>> screen: "Talk English, expect English text".
>>>>>   That prepares the users for how the call is best started.
>>>>>
>>>>>   Alternatively, the answering party can be provided with options 
>>>>> for selection among the common languages before the call is 
>>>>> answered. E.g.
>>>>>   "The far end user can receive ASL __ and written English __, 
>>>>> which do you want to produce?"
>>>>>   "The far end user can produce ASL ___ and written English ___, 
>>>>> which do you want to receive?"
>>>>>   The result goes into the coding of the hlang attributes in the 
>>>>> answer.
>>>>>   The answer will be presented to the offeror on the screen by e.g.
>>>>>   "Sign ASL, prepare to receive ASL".
>>>>>
>>>>>   By following the advice on the screen, the call will start 
>>>>> smoothly. Nothing prevents the users to vary the use of languages 
>>>>> and media by mutual agreement after the initial exchange during 
>>>>> the call.
>>>>>
>>>>>   Wide variations from these examples are imaginable.
>>>>>   Gunnar
>>>>
>>>>   While this sounds helpful, it isn't current practice. I don't 
>>>> know what it will take make it common practice. Perhaps the draft 
>>>> should note this as an issue.
>>  The draft makes this possible. The whole idea of it is to enable a 
>> smooth start of the call with the participants using negotiated 
>> languages. It is a problem today, and the draft says it solves it. I 
>> would guess that most applications will prefer to use the first 
>> mechanism I described, where the application makes the decision and 
>> tells the user which language(s) will make the call start smoothly.
>>
>>>
>>>  I'd rather leave this for other documents. For example, Gunner has 
>>> a few drafts that build on this one.
>>  What do you want to leave?  The examples above are nothing new and 
>> contain no issue and nothing that we intend to specify because we do 
>> not specify user interactions. It is the natural use of the current 
>> draft.  How else did you intend to use it?
>
> Paul wrote "Perhaps the draft should note this as an issue."  I'd 
> rather leave the UI issues out of the draft.  The draft already says 
> it does not discuss how users are informed.
>
<GH> Yes, and I think it is also not the task of the draft to tell how 
it can become common practice to implement it, if that was the issue 
Paul saw.
My first impression was that you both found my examples of how to use 
the draft unexpected. But that was apparently not the case.

/Gunnar

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