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

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.

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