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

[Randall Gellens <[e-mail]>]

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.

-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly selected tag: ---------------
If you can't be a good example, at least be a horrible warning.