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

"Randall Gellens" <rg+ietf@randy.pensive.org> Mon, 19 February 2018 03:20 UTC

Return-Path: <rg+ietf@randy.pensive.org>
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 EF18A126C22 for <slim@ietfa.amsl.com>; Sun, 18 Feb 2018 19:20:41 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level:
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, T_RP_MATCHES_RCVD=-0.01] 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 KNKG-1W3Qr81 for <slim@ietfa.amsl.com>; Sun, 18 Feb 2018 19:20:40 -0800 (PST)
Received: from turing.pensive.org (turing.pensive.org [99.111.97.161]) by ietfa.amsl.com (Postfix) with ESMTP id 6748A1201FA for <slim@ietf.org>; Sun, 18 Feb 2018 19:20:40 -0800 (PST)
Received: from [172.20.59.46] (99.111.97.161) by turing.pensive.org with ESMTP (EIMS X 3.3.9); Sun, 18 Feb 2018 19:21:34 -0800
From: "Randall Gellens" <rg+ietf@randy.pensive.org>
To: "Bernard Aboba" <bernard.aboba@gmail.com>
Cc: "Gunnar =?utf-8?q?Hellstr=C3=B6m?=" <gunnar.hellstrom@omnitor.se>, slim@ietf.org
Date: Sun, 18 Feb 2018 19:20:36 -0800
X-Mailer: MailMate Trial (1.10r5443)
Message-ID: <7D3A0148-DFAA-459B-B5AF-C85D59E6313B@randy.pensive.org>
In-Reply-To: <9B27941C-CAE7-4162-8E8B-3BFA60921578@gmail.com>
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>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: quoted-printable
Archived-At: <https://mailarchive.ietf.org/arch/msg/slim/hHR5khsG6cfHUyu5_bHv1mDkyoA>
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 03:20:42 -0000

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.

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

—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