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

[Randall Gellens <[e-mail]>]

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.

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

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


-- 
Randall Gellens
Opinions are personal;    facts are suspect;    I speak for myself only
-------------- Randomly selected tag: ---------------
Performance is easier to add than clarity.