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

[Paul Kyzivat <[e-mail]>]

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.

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