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

Gunnar Hellström <gunnar.hellstrom@omnitor.se> Mon, 19 February 2018 07:43 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 886B01201FA for <slim@ietfa.amsl.com>; Sun, 18 Feb 2018 23:43:32 -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, RCVD_IN_DNSWL_LOW=-0.7, 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 p5H3Irp84wfc for <slim@ietfa.amsl.com>; Sun, 18 Feb 2018 23:43:30 -0800 (PST)
Received: from bin-vsp-out-03.atm.binero.net (bin-mail-out-06.binero.net [195.74.38.229]) (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 13765126CBF for <slim@ietf.org>; Sun, 18 Feb 2018 23:43:29 -0800 (PST)
X-Halon-ID: 8fb60c0b-1548-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 8fb60c0b-1548-11e8-8760-0050569116f7; Mon, 19 Feb 2018 08:43:23 +0100 (CET)
To: Randall Gellens <rg+ietf@randy.pensive.org>, Bernard Aboba <bernard.aboba@gmail.com>
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> <7D3A0148-DFAA-459B-B5AF-C85D59E6313B@randy.pensive.org>
From: =?UTF-8?Q?Gunnar_Hellstr=c3=b6m?= <gunnar.hellstrom@omnitor.se>
Message-ID: <811b57b1-2444-f206-b860-2034ce1b8ea4@omnitor.se>
Date: Mon, 19 Feb 2018 08:43:23 +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: <7D3A0148-DFAA-459B-B5AF-C85D59E6313B@randy.pensive.org>
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 8bit
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/slim/TC8z-B93LdehuqcKXo88jPcTNpI>
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: Mon, 19 Feb 2018 07:43:32 -0000

Den 2018-02-19 kl. 04:20, skrev Randall Gellens:
> On 18 Feb 2018, at 11:56, Bernard Aboba wrote:
>
>> 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.
>
> In that case, let’s move forward with the draft as-is, which does only 
> permits one language in the answer.
<GH>As explained in another reply, I do not see it adding pointless 
confusion. It adds clarity about the language situation and prepares for 
a smooth start of the dialogue.
>
>> 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?
>
> I don’t think it’s necessary, because we don’t expect non-offered 
> languages to be in an answer except in unusual edge cases.
<GH>It is the opposite situation that is of interest to express, when 
the answerer has some limited capability in one of the offered languages 
and a much higher preference for a non-offered language in the same 
media. So the answer contains both, with the non-offered first. That 
explains the language situation well to the offeror, and makes it 
possible for both parties to accommodate to the situation by whatever 
means and resources they have; either go with only the common language 
or do something to make it easier for the answering party.

Indicating a non-offered language in an answer with lower preference 
than a common language is of less interest. If you already agree on a 
language with good preference, why tell about your non-matched lower 
preference capabilities? But we do not need more rules about how 
indications for offered and non-offered languages are mixed or not.



/Gunnar


>
> —Randall
>
>>
>>> On Feb 18, 2018, at 10:40 AM, Randall Gellens 
>>> <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> 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> 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> 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
>>>>>>>
>>>>>>> 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
>>>>>>> "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
>>>>>>>> https://www.ietf.org/mailman/listinfo/slim
>>>>>>>
>>>>>>>
>>>>>>> -- 
>>>>>>> -----------------------------------------
>>>>>>> Gunnar Hellström
>>>>>>> Omnitor
>>>>>>> gunnar.hellstrom@omnitor.se
>>>>>>> +46 708 204 288
>>>>>>
>>>>>>
>>>>>>
>>>>>> --Randall
>>>>>>
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> 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
>>>>
>
>
>
>
> --Randall
>
> _______________________________________________
> 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