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

[Randall Gellens <[e-mail]>]

I do not agree that changes are needed now.  I 
also do not agree that, in general, it is 
difficult to relax restrictions in future 
extensions or updates.  In my experience, it is 
much easier to relax a restriction than it is to 
introduce it.

At 9:55 AM +0100 1/9/18, 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]
>
>  _______________________________________________
>  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: ---------------
I loathe housework.  You make beds, wash dishes
-- and six months later you have to start all over again.
                                           --Joan Rivers