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

Gunnar Hellström <gunnar.hellstrom@omnitor.se> Mon, 19 February 2018 15:24 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 2B703124BAC for <slim@ietfa.amsl.com>; Mon, 19 Feb 2018 07:24:38 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.6
X-Spam-Level:
X-Spam-Status: No, score=-2.6 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, 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 gj0l4mWb9QNT for <slim@ietfa.amsl.com>; Mon, 19 Feb 2018 07:24:34 -0800 (PST)
Received: from bin-vsp-out-01.atm.binero.net (bin-mail-out-05.binero.net [195.74.38.228]) (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 0DD6E127873 for <slim@ietf.org>; Mon, 19 Feb 2018 07:24:24 -0800 (PST)
X-Halon-ID: f120bdb1-1588-11e8-93cf-005056917a89
Authorized-sender: gunnar.hellstrom@omnitor.se
Received: from [192.168.2.136] (unknown [87.96.161.61]) by bin-vsp-out-01.atm.binero.net (Halon) with ESMTPSA id f120bdb1-1588-11e8-93cf-005056917a89; Mon, 19 Feb 2018 16:24:14 +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> <7D3A0148-DFAA-459B-B5AF-C85D59E6313B@randy.pensive.org> <CAOW+2dvgJU_rfGKnU3ZfJ1+=YCP6up=DnW-rGLuX-6n0fa9-GA@mail.gmail.com>
From: Gunnar Hellström <gunnar.hellstrom@omnitor.se>
Message-ID: <20f21dd8-33df-b306-2b58-d43de8fceb69@omnitor.se>
Date: Mon, 19 Feb 2018 16:24:18 +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: <CAOW+2dvgJU_rfGKnU3ZfJ1+=YCP6up=DnW-rGLuX-6n0fa9-GA@mail.gmail.com>
Content-Type: multipart/alternative; boundary="------------F77690489881A85526350245"
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/slim/6bTIa2HjWV-tH1fWyXqjZh86WzM>
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 15:24:38 -0000

Den 2018-02-19 kl. 15:48, skrev Bernard Aboba:
> 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).
<GH>We would create even more unbalance than we already have between 
what is allowed within one media compared to what is allowed in multiple 
media. The wording is now per media and direction. If we introduce a 
restriction to one language per media and direction, we can still have 
one offered language in the answer for one media and direction and one 
non-offered language in the answer for another media and the same 
direction. That would mean that one of these can be selected for use.

The fact that the answering party bothered to include the non-offered 
language in another media can likely be understood as an indication of 
preference for that language. The inclusion of the common language in 
one media can be understood as a safety measure to have some language 
that is surely possible to start with.
I think that is good and we should not limit the opportunity to provide 
such answers in multiple media. Why should we then introduce limitations 
for the similar indication within one media?

The edge cases do not hurt, and it is up to the applications to decide 
how much flexibility and clarity about the language situation they will 
provide to the user.
>
> " 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 <mailto: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
>             <mailto:rg%2Bietf@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 <tel:%2B46%20708%20204%20288>
>
>
>
>
>                         --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 <tel:%2B46%20708%20204%20288>
>
>
>
>
>
>
>     --Randall
>
>

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