Re: [Slim] Negotiation issue in draft-ietf-slim-negotiating-human-language

Gunnar Hellström <gunnar.hellstrom@omnitor.se> Sun, 18 February 2018 20:20 UTC

Return-Path: <gunnar.hellstrom@omnitor.se>
X-Original-To: slim@ietfa.amsl.com
Delivered-To: slim@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 1C7D51242EA for <slim@ietfa.amsl.com>; Sun, 18 Feb 2018 12:20:12 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Level:
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RCVD_IN_MSPIKE_H2=-0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id DODoUKHfufaL for <slim@ietfa.amsl.com>; Sun, 18 Feb 2018 12:20:09 -0800 (PST)
Received: from bin-vsp-out-03.atm.binero.net (vsp-unauthed02.binero.net [195.74.38.227]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0108A12422F for <slim@ietf.org>; Sun, 18 Feb 2018 12:20:08 -0800 (PST)
X-Halon-ID: 197911de-14e9-11e8-8760-0050569116f7
Authorized-sender: gunnar.hellstrom@omnitor.se
Received: from [192.168.2.136] (unknown [87.96.161.61]) by bin-vsp-out-03.atm.binero.net (Halon) with ESMTPSA id 197911de-14e9-11e8-8760-0050569116f7; Sun, 18 Feb 2018 21:20:02 +0100 (CET)
To: Bernard Aboba <bernard.aboba@gmail.com>, Randall Gellens <rg+ietf@randy.pensive.org>
Cc: slim@ietf.org
References: <CAOW+2dtV5EaL_xTLSJNSiNjUZp-ZzFa2cMPUvSb65FRyYSNB1Q@mail.gmail.com> <6754134E-63FD-4212-90D5-D07293EFE36B@randy.pensive.org> <09dcffcc-a65d-65d8-614d-fa12b790dd4f@omnitor.se> <CAOW+2ds680XB2v9TavT00_CAQAo9FHmDbfXNodeZ9=NFh1=jEA@mail.gmail.com> <EB90D6A9-FE9A-4DC2-9C0D-EC7EDF513F7E@randy.pensive.org> <5c33acfd-8853-4254-c6b1-fa05ea4901fd@omnitor.se> <CAOW+2dvuAjON1+pi2renF+fD4qYMpUhq5zPDhF9EdepHO8X18g@mail.gmail.com> <608E5933-9EB0-489D-A845-39018CF68127@randy.pensive.org> <9B27941C-CAE7-4162-8E8B-3BFA60921578@gmail.com>
From: =?UTF-8?Q?Gunnar_Hellstr=c3=b6m?= <gunnar.hellstrom@omnitor.se>
Message-ID: <5551ded6-5bc4-7bc9-54e4-559d17955802@omnitor.se>
Date: Sun, 18 Feb 2018 21:20:02 +0100
User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0
MIME-Version: 1.0
In-Reply-To: <9B27941C-CAE7-4162-8E8B-3BFA60921578@gmail.com>
Content-Type: multipart/alternative; boundary="------------2D903DD4B3F54F01BDE7B606"
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/slim/_z87Wi36q5sqzO2OWIq6ctxiomQ>
Subject: Re: [Slim] Negotiation issue in draft-ietf-slim-negotiating-human-language
X-BeenThere: slim@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Selection of Language for Internet Media <slim.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/slim>, <mailto:slim-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/slim/>
List-Post: <mailto:slim@ietf.org>
List-Help: <mailto:slim-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/slim>, <mailto:slim-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 18 Feb 2018 20:20:12 -0000


Den 2018-02-18 kl. 20:56, skrev Bernard Aboba:
> The fact that Answers containing “pointless confusion” are allowed 
> means that implementations need to be prepared to handle these edge 
> cases. I see no benefit arising from this.
>
> Why not require that an Answer place mutually supported language(s) 
> before languages only supported by the Answerer? In what situations 
> would it be necessary to do something else?
<GH>
Example within one media:  You might get an offer for spoken English, 
you feel quite unsure about talking English, but want to accept that but 
also express that your strong preference is spoken French. This is 
expressed by listing French before English in the answer. The offering 
party can then understand that it is possible to start the conversation 
in English, but if problems appear, it might be better to invoke a 
French - English interpreter, or hand it over to a French-speaking agent.

Example with two media: You might get an offer for spoken English in 
audio and a text stream, without any language indication. You do not 
hear so well, so you can barely manage a spoken conversation in English. 
Therefore you add written English in the text stream in the answer in 
the quite likely hope that the offering party can use English text. You 
would like to indicate strong preference for receiving English text 
before receiving English voice, but that is not possible with the 
current specification, so you need to hope that the offfering party can 
guess that from your insertion of reception of English text in the answer.

I do not think these examples provide any pointless confusion, but 
rather more clarity about the conditions for a successful conversation.

/Gunnar
>
> On Feb 18, 2018, at 10:40 AM, Randall Gellens 
> <rg+ietf@randy.pensive.org <mailto:rg+ietf@randy.pensive.org>> wrote:
>
>> We don't expect an answer to contain a non-offered language except in 
>> unusual cases. What's in an answer is decided by policies at the 
>> answerer. I don't think we need to get into an exercise of trying to 
>> describe what is permitted vs forbidden for such edge cases. I think 
>> we can assume that the people who create the policies want to enable 
>> communication and not sow pointless confusion.
>>
>> Sent from my iPhone
>>
>> On Feb 18, 2018, at 11:27 PM, Bernard Aboba <bernard.aboba@gmail.com 
>> <mailto:bernard.aboba@gmail.com>> wrote:
>>
>>> Gunnar said:
>>>
>>> "That will happen if you decide to answer with a language that was 
>>> not in the offer. But it is better than answering with no language 
>>> indication and it indicates how you might answer the call."
>>>
>>> [BA] I understand how an Answerer could respond only with 
>>> language(s) not in the Offer.  But if the Answerer can support some 
>>> of the offered languages, what are the restrictions on non-offered 
>>> languages?
>>> Can an Answerer put a non-offered language first in the preference 
>>> list and an offered language in a less preferred position?  Should 
>>> it be able to include a non-offered language at all?  If you offer 
>>> English and
>>> Swedish and receive an Answer with Swahili and Swedish, that could 
>>> result in confusion at best.
>>>
>>> On Sat, Feb 17, 2018 at 5:20 PM, Gunnar Hellström 
>>> <gunnar.hellstrom@omnitor.se <mailto:gunnar.hellstrom@omnitor.se>> 
>>> wrote:
>>>
>>>     I agree with Randall. No more normative or descriptive language
>>>     is needed. There is already a warning against providing language
>>>     indications that will be hard to match. That will happen if you
>>>     decide to answer with a language that was not in the offer. But
>>>     it is better than answering with no language indication and it
>>>     indicates how you might answer the call.
>>>
>>>     There is however one small adjustment to do. The sentence about
>>>     having the languages in preference order in the lists should be
>>>     included also in the paragraph about the answer in 5.2.  Or it
>>>     could be pulled out from the paragraph about the offer and put
>>>     in a common paragraph below both paragraphs about the offer and
>>>     the answer. And the lists should be in plural in the sentence.
>>>     Here the sentence is attached last in the paragraph about the
>>>     answer:
>>>     -----------------------------5.2 paragraph about the answer,
>>>     with new sentence attached
>>>     last------------------------------------------
>>>
>>>       In an answer, 'hlang-send' is a list of one or more languages the answerer might send if
>>>         using the media for language (which in most cases contains one or more of the
>>>         languages in the offer's 'hlang-recv'), and 'hlang-recv' is a list of one or more of the
>>>         languages the answerer is prepared to receive if using the media for
>>>         language (which in most cases contains one or more of the languages in the offer's
>>>         'hlang-send'). The lists of languages are in preference order (first is most
>>>         preferred).
>>>
>>>     ----------------------------------------------------------------------------------------------------------------------------------------------------------
>>>     /Gunnar
>>>
>>>
>>>
>>>
>>>
>>>
>>>     Den 2018-02-17 kl. 10:52, skrev Randall Gellens:
>>>>
>>>>     Hi Bernard,
>>>>
>>>>     Putting a language in an answer that was not in the offer is an
>>>>     unusual case (as the text says). I don’t think we need to add
>>>>     more text (normative or descriptive) about it.
>>>>
>>>>     —Randall
>>>>
>>>>     On 16 Feb 2018, at 19:36, Bernard Aboba wrote:
>>>>
>>>>         Yes, the proposed changes seem good. One question: is there
>>>>         enough normative language about adding languages to an
>>>>         Answer that were not in the Offer? For example, can this
>>>>         only occur if the Answerer has no languages in common with
>>>>         the Offerer? Or can an Answerer add any languages(s) they
>>>>         would put into an Offer if roles were reversed?
>>>>
>>>>         On Fri, Feb 16, 2018 at 02:39 Gunnar Hellström
>>>>         <gunnar.hellstrom@omnitor.se
>>>>         <mailto:gunnar.hellstrom@omnitor.se>> wrote:
>>>>
>>>>             I find that the changes to version -23 prepared by
>>>>             Randall and provided in this archive mail are good:
>>>>             https://www.ietf.org/mail-archive/web/slim/current/msg01289.html
>>>>             <https://www.ietf.org/mail-archive/web/slim/current/msg01289.html>
>>>>
>>>>             That version allows answers to contain languages not
>>>>             contained in the offer (that was already allowed and
>>>>             well specified in version -23),
>>>>             and allows multiple languages per media and direction
>>>>             in the answer.
>>>>
>>>>             I think both of these conditions are good and important
>>>>             for successful use of the draft.
>>>>             We need to imagine all kinds of feasible applications,
>>>>             e.g. the decision on including interpreting resources
>>>>             taken by the offeror after receiving the answer. That
>>>>             calls for providing the full and true picture about the
>>>>             supported languages in the answer.
>>>>
>>>>             So, I repeat my comment from
>>>>             https://www.ietf.org/mail-archive/web/slim/current/msg01297.html
>>>>             <https://www.ietf.org/mail-archive/web/slim/current/msg01297.html>
>>>>             "I find the diff you sent to be good, and also version
>>>>             -23 solving all other issues in a good way. So, I vote
>>>>             for applying your proposed changes on -23 and hope that
>>>>             that can be the final version."
>>>>
>>>>             Gunnar
>>>>>
>>>>>
>>>>>             --Randall
>>>>>
>>>>>             _______________________________________________
>>>>>             SLIM mailing list
>>>>>             SLIM@ietf.org <mailto:SLIM@ietf.org>
>>>>>             https://www.ietf.org/mailman/listinfo/slim
>>>>>             <https://www.ietf.org/mailman/listinfo/slim>
>>>>
>>>>             -- 
>>>>             -----------------------------------------
>>>>             Gunnar Hellström
>>>>             Omnitor
>>>>             gunnar.hellstrom@omnitor.se
>>>>             <mailto:gunnar.hellstrom@omnitor.se>
>>>>             +46 708 204 288
>>>>
>>>>
>>>>
>>>>     --Randall
>>>>
>>>>
>>>>
>>>>     _______________________________________________
>>>>     SLIM mailing list
>>>>     SLIM@ietf.org <mailto:SLIM@ietf.org>
>>>>     https://www.ietf.org/mailman/listinfo/slim
>>>>     <https://www.ietf.org/mailman/listinfo/slim>
>>>
>>>     -- 
>>>     -----------------------------------------
>>>     Gunnar Hellström
>>>     Omnitor
>>>     gunnar.hellstrom@omnitor.se <mailto:gunnar.hellstrom@omnitor.se>
>>>     +46 708 204 288
>>>
>>>
>
>
> _______________________________________________
> SLIM mailing list
> SLIM@ietf.org
> https://www.ietf.org/mailman/listinfo/slim

-- 
-----------------------------------------
Gunnar Hellström
Omnitor
gunnar.hellstrom@omnitor.se
+46 708 204 288