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-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?

Gunnar



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