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: Gunnar Hellström <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 >
- [Slim] Negotiation issue in draft-ietf-slim-negot… Bernard Aboba
- Re: [Slim] Negotiation issue in draft-ietf-slim-n… Randall Gellens
- Re: [Slim] Negotiation issue in draft-ietf-slim-n… Gunnar Hellström
- Re: [Slim] Negotiation issue in draft-ietf-slim-n… Bernard Aboba
- Re: [Slim] Negotiation issue in draft-ietf-slim-n… Randall Gellens
- Re: [Slim] Negotiation issue in draft-ietf-slim-n… Gunnar Hellström
- Re: [Slim] Negotiation issue in draft-ietf-slim-n… Bernard Aboba
- Re: [Slim] Negotiation issue in draft-ietf-slim-n… Randall Gellens
- Re: [Slim] Negotiation issue in draft-ietf-slim-n… Gunnar Hellström
- Re: [Slim] Negotiation issue in draft-ietf-slim-n… Bernard Aboba
- Re: [Slim] Negotiation issue in draft-ietf-slim-n… Gunnar Hellström
- Re: [Slim] Negotiation issue in draft-ietf-slim-n… Randall Gellens
- Re: [Slim] Negotiation issue in draft-ietf-slim-n… Gunnar Hellström
- Re: [Slim] Negotiation issue in draft-ietf-slim-n… Bernard Aboba
- Re: [Slim] Negotiation issue in draft-ietf-slim-n… Gunnar Hellström
- Re: [Slim] Negotiation issue in draft-ietf-slim-n… Martin J. Dürst
- Re: [Slim] Negotiation issue in draft-ietf-slim-n… Randall Gellens