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

Bernard Aboba <bernard.aboba@gmail.com> Mon, 19 February 2018 14:48 UTC

Return-Path: <bernard.aboba@gmail.com>
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 A6EAB12762F for <slim@ietfa.amsl.com>; Mon, 19 Feb 2018 06:48:37 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.com
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 ByGmyTt_EQak for <slim@ietfa.amsl.com>; Mon, 19 Feb 2018 06:48:35 -0800 (PST)
Received: from mail-ua0-x236.google.com (mail-ua0-x236.google.com [IPv6:2607:f8b0:400c:c08::236]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DEDC51276AF for <slim@ietf.org>; Mon, 19 Feb 2018 06:48:34 -0800 (PST)
Received: by mail-ua0-x236.google.com with SMTP id w6so1577957uae.10 for <slim@ietf.org>; Mon, 19 Feb 2018 06:48:34 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=c+gEH+ug3jmDOKbaT+kbYeSIds3h6EYqJEsi1i55M14=; b=puGWMOR3z6kXD01I+nAuXUJNftjQOaPJC+NL5gQaED7mpBpOVdadwFaEEogi+Zm6vf 8zHo60ZFn3JyiOj7UV72JTWEJG400tI/CNTJ1lPv1nfMXP1COEwBGu+LEL/Y2fUtGnIo T37DuWPJuau22TsZLP7jXOYuZVDW42qeoz0Z7QGQON5oVjCw+4W+CZHA4HArF5YmvTg1 JV0psN48mam3tS9APMEif7+rpOurVV/rtzB6J+ecmIj8geh026vOyN1jk1Gi1m/8GiV0 jMt+m7qZHad+msjafisFxvE3jRJCDNN3p4m+aG7xRc3l8UsgAeis+kA891xHwEWEHH/d LPyg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=c+gEH+ug3jmDOKbaT+kbYeSIds3h6EYqJEsi1i55M14=; b=fs4bkdb6DGHwPli+9aIwfmg711ulApTt9Zxh1AkSRb3OLx3Pv16/ulSMdIn4hv+B+p kmfEFqos3ZvrbVz94W62O4j5uabf7AqsSKKIuiVM+xB+MEduYzZfBnZ3dZ3JDqEhi1bv Nw/C2Gori8WTUQcVVtn1Dq/1Yr6U3a9xnp5R0un4kx1I7EgYzDyx6SjPM409J8B73UNG QDxKKa+cbGPtJLjxdj5/NRpKBBeGUDIHF3NCJudw5cN/A9oTbJU5oqM8t3PDnhYU9+wq CBDg3vY9quCLzhhHjKoAGey34mXze0wwwMoSkFVBYy89uioPZdFQFNKxqJefpmkO6aKF mxpw==
X-Gm-Message-State: APf1xPA/Pq+Xpl+iVJxkJJaqmfGLJe/YbP+kImmmw++j2gI3kfUsCtkO mh8NGvisF3qsnDrZulmVLnMjELAz4zstjflLIRE=
X-Google-Smtp-Source: AH8x2263bqen80ZVgEffuU5wCc37L3q0vUzVJHohv76rL9ufmzEBSDTfzdgFBB/W4xcyENuiJ6zR7Y5KYyT5cppEIJc=
X-Received: by 10.176.79.7 with SMTP id n7mr11428020uah.64.1519051713513; Mon, 19 Feb 2018 06:48:33 -0800 (PST)
MIME-Version: 1.0
Received: by 10.176.10.24 with HTTP; Mon, 19 Feb 2018 06:48:13 -0800 (PST)
In-Reply-To: <7D3A0148-DFAA-459B-B5AF-C85D59E6313B@randy.pensive.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: Bernard Aboba <bernard.aboba@gmail.com>
Date: Mon, 19 Feb 2018 09:48:13 -0500
Message-ID: <CAOW+2dvgJU_rfGKnU3ZfJ1+=YCP6up=DnW-rGLuX-6n0fa9-GA@mail.gmail.com>
To: Randall Gellens <rg+ietf@randy.pensive.org>
Cc: =?UTF-8?Q?Gunnar_Hellstr=C3=B6m?= <gunnar.hellstrom@omnitor.se>, slim@ietf.org
Content-Type: multipart/alternative; boundary="f403043c3924c78f03056591c94e"
Archived-At: <https://mailarchive.ietf.org/arch/msg/slim/D26F8_xk9bacRwqwus2-56eeGLw>
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 14:48:38 -0000

Randall said:

"In that case, let’s move forward with the draft as-is, which does only
permits one language in the answer."

[BA] I'm beginning to think that is a better idea, since the edge cases are
dramatically reduced (e.g. the one language would be one of the Offered
languages, unless none are supported).

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

[BA] If there were only one language in the Answer that is more likely to
be true, which is a good argument for that approach.


On Sun, Feb 18, 2018 at 10:20 PM, Randall Gellens <rg+ietf@randy.pensive.org
> wrote:

> 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-arch
>>>>>>> ive/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
>