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






>
>     Thanks,
>     Paul
>
> On 1/9/18 3:55 AM, Gunnar Hellström wrote:
>> Den 2018-01-08 kl. 23:02, skrev Randall Gellens:
>>> At 10:38 PM +0100 1/8/18, Gunnar Hellström wrote:
>>>
>>>>  Den 2018-01-08 kl. 20:38, skrev Randall Gellens:
>>>>>  At 1:36 PM -0500 1/8/18, Paul Kyzivat wrote:
>>>>>
>>>>>>   On 1/8/18 1:10 PM, Randall Gellens wrote:
>>>>>>
>>>>>>>       The term "negotiation" is used here rather than 
>>>>>>> "indication" because
>>>>>>>       human language (spoken/written/signed) can be negotiated 
>>>>>>> in the same
>>>>>>>       manner as media (audio/text/video) and codecs. For 
>>>>>>> example, if we
>>>>>>>       think of a user calling an airline reservation center, the 
>>>>>>> user may
>>>>>>>       have a set of languages he or she speaks, with perhaps 
>>>>>>> preferences
>>>>>>>       for one or a few, while the airline reservation center 
>>>>>>> will support a
>>>>>>>       fixed set of languages.  Negotiation should select the 
>>>>>>> user's most
>>>>>>>       preferred language that is supported by the call center. 
>>>>>>> Both sides
>>>>>>>       should be aware of which language was negotiated. This is
>>>>>>>       conceptually similar to the way other aspects of each 
>>>>>>> media stream
>>>>>>>       are negotiated using SDP (e.g., media type and codecs).
>>>>>>
>>>>>>   Certainly it will be common for the choices are mutually 
>>>>>> exclusive. For instance, a caller *might* offer both French and 
>>>>>> Chinese. The callee (a call center) may have agents that speak 
>>>>>> each, but may well not have any agents that speak both.
>>>>>>
>>>>>>   OTOH, it is *possible* that they do have somebody who supports 
>>>>>> both. If so, seems like it would be good to indicate that both 
>>>>>> are supported.
>>>>>
>>>>>  Yes, although the additional gain in functionality is small 
>>>>> relative to the additional complexity.  The draft explicitly rules 
>>>>> this out of scope.  Section 3 says:
>>>>>
>>>>>     (Negotiating multiple simultaneous languages within a media 
>>>>> stream is
>>>>>     out of scope of this document.)
>>>>  <GH> No, that is a different thing. We have agreed and made 
>>>> efforts to express that providing multiple language indications per 
>>>> direction does not imply that they all must be used simultaneously. 
>>>> They (usually) only form a list to select from for use in the session.
>>>>
>>>>  I have many times during our discussions thought about the 
>>>> proposal that Paul made now, and wondered if we gain or lose by 
>>>> having the restriction of only one language per media and direction 
>>>> in the answer. We might have higher complexity and longer delay 
>>>> before the answer when we have the current limitation. This  is 
>>>> because it can be hard for the application to take the decision on 
>>>> its own on the single language to indicate in the answer, and 
>>>> therefore a user interaction needed to ask the user how to answer. 
>>>> If support of more than one language per media and direction is 
>>>> allowed (but not simultaneously), then it is easier to make an 
>>>> automatic match by the device and include all common languages in 
>>>> the answer.
>>>>
>>>>  However including more than one language per media and direction 
>>>> in the answer puts the users in more uncertainty about in what 
>>>> language the session will begin.
>>>>
>>>>  We could allow indication of multiple languages per media and 
>>>> direction in the answer and let the application decide if it shall 
>>>> make it easy for itself by indicating all common languages or easy 
>>>> for the users by indicating one language per media and direction.
>>>>
>>>>  We also have the wording that the languages in the answer does not 
>>>> need to be selected from what was provided in the offer by the 
>>>> formulation: "(which in most cases is one of the languages in the 
>>>> offer's 'hlang-recv') etc."
>>>
>>> This is because there may be no languages in common but the call 
>>> proceeds anyway.  The usual example is an emergency call placed by a 
>>> user who does not speak any language that the PSAP can support, even 
>>> with language translation services. Just being able to hear what is 
>>> happening may be useful to the PSAP call taker, better than not 
>>> having a call at all.
>> <GH> No, the parenthesis introduces an important opportunity for the 
>> answerer to propose a language that was not in the offer, but may be 
>> possible to use as a first try for getting some communication going 
>> anyway. That can be beneficial for both sending and receiving. If it 
>> does not work for the users, they are free to try other alternatives 
>> during the session.
>>
>> A question: Do you regard it to also be allowed for the answerer to 
>> include a language in a media that had no hlang attribute in the 
>> offer? Imagine a hearing caller offering only spoken languages in 
>> audio, but including text media in the offer, calling a deaf person 
>> who cannot use spoken language, and therefore takes a chance to 
>> include written language indication in text media.  The ABNF in -20 
>> allows it, and my interpretation of the wording in 5.2 is that it is 
>> allowed. There may be other views.
>> The clean way is of course to accept the call without languages and 
>> make a re-INVITE with languages in text media so that a complete 
>> language negotiation can be performed, but that adds complexity.
>>
>> RFC 4796 has specific wording to tell that the content attribute is 
>> allowed in an answer even if it did not appear in the offer. Maybe we 
>> should have had a similar statement.
>>
>>
>>>
>>>>
>>>>  When there is no match, maybe the answerer want to indicate all 
>>>> support it has, for example expressing in response to a request to 
>>>> use Spanish:  "No, I cannot understand Spanish but I can understand 
>>>> spoken Portuguese and French and Italian", in a hope to get a 
>>>> conversation going.
>>>>
>>>>  In summary: I support Paul's proposal to relax the rules and leave 
>>>> to the application to decide how to compose the answer.
>>>
>>> The current limitation has been agreed by the working group. I see 
>>> Paul's suggestion as a trade-off between a capability that might be 
>>> nice to have but is not required, and additional complexity; I do 
>>> not see it as a significant defect.  It is not a show-stopper.  It 
>>> could be relaxed in a future extension or revision. Consider how 
>>> many years we have been trying to get this simple feature published 
>>> so it can be used.  And now, finally, after so many arguments (many 
>>> of which were pointless) and so many revisions, and so much debate 
>>> over simple wording, you propose that we go back to the WG and 
>>> reopen debate and restart the series of last calls and discussions.  
>>> I think this is a mistake.  I object to it.
>> <GH>The discussion and proposal was just a result of the difference 
>> between the wording about the answer and the wording about the syntax 
>> in 5.2. Selection of one of the interpretations was needed. It would 
>> be less complex for the applications to allow multiple languages in 
>> the attribute in the answer than deciding on one single language. 
>> That could save the need for complex user interaction to make the 
>> decision. The wording does not require simultaneous use during the 
>> session that is said to be out of scope. It is only that the possible 
>> alternatives would be indicated to the offeror in order of preference.
>> It may however increase the complexity for the users to take the 
>> decision instead of being told by the application which language to 
>> use, so it would be best to leave it to the application to decide on 
>> how many alternatives are provided in the answer.
>> I do not think that the WG has been very specific about this choice 
>> since both interpretations have been there for a long time in the draft.
>> It is hard to relax restrictions in later revisions. Without protocol 
>> preparations for extensions, interop problems are easily introduced.
>>
>> /Gunnar
>>>
>>>>
>>>>>
>>>>>  This could, of course, be added in a future extension or revision.
>>>>>
>>>>>>
>>>>>>       Thanks,
>>>>>>       Paul
>>>>>>
>>>>>>   _______________________________________________
>>>>>>   SLIM mailing list
>>>>>>   [e-mail]
>>>>>>   https://www.ietf.org/mailman/listinfo/slim
>>>>>
>>>>>
>>>>
>>>>  --
>>>>  -----------------------------------------
>>>>  Gunnar Hellström
>>>>  Omnitor
>>>>  [e-mail]
>>>>  [phone]
>>>>
>>>>  _______________________________________________
>>>>  SLIM mailing list
>>>>  [e-mail]
>>>>  https://www.ietf.org/mailman/listinfo/slim
>>>
>>>
>>
>

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