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

Bernard Aboba <bernard.aboba@gmail.com> Sun, 18 February 2018 15:28 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 8C7EB1205F0 for <slim@ietfa.amsl.com>; Sun, 18 Feb 2018 07:28:09 -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 W3TT7HTFBD48 for <slim@ietfa.amsl.com>; Sun, 18 Feb 2018 07:28:06 -0800 (PST)
Received: from mail-vk0-x234.google.com (mail-vk0-x234.google.com [IPv6:2607:f8b0:400c:c05::234]) (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 704941201F8 for <slim@ietf.org>; Sun, 18 Feb 2018 07:28:06 -0800 (PST)
Received: by mail-vk0-x234.google.com with SMTP id t201so4379033vke.8 for <slim@ietf.org>; Sun, 18 Feb 2018 07:28:06 -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=XyQfeiQisxuXakMWxAedizamAcCaQEL1LhJCoCr/p7g=; b=pRNnmOZyKNryONl6fnwjHCv4U0svIcrikeDoqVEUXK3wR1tkUtsSGIgLAMeNk3HLvr elfW7FZKDONp66IcFBGevS6YB1HEyGyor6d1IcQN1IGkyRR2zmSC86bF7PFxtsbI6bQu 62so0JtFbT6WIvf1xogPwDDtl8Cx5cTg1t04p9jELw9AYKzf51Yta4oYEIt2d5o70uQg EeAVGsyVWuDZkpQ8ZNF2fsNW0RMxNmnSyIa8VuhYldIbjJKfdkez2N0DoXKfjOqOGQel bwKWPEdcNzmxz9qXmiExu4E0NJPssJMxfZauz/4g4rvqphsc42d8OaW/sDnGeONivKZW 7iUA==
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=XyQfeiQisxuXakMWxAedizamAcCaQEL1LhJCoCr/p7g=; b=d6MTbLU73KyeUOUIdafk9ng91gA5t14/ySQYW4hOB1I5xfWtvgIchzKy22tkF5DLHy s8oYuV7qoBzKZbhxFRsU9Q/4P3ZFNbbUNn18AD3xsG1C+W3/d41wuqWoDiN+/PZ1DxBT bn4ez7IGYEPNW2YhWT+GE5lvo93AbEAx3dPnN5cwxHocyEK4hjgfrTxZuHgIOnOItXym 63nZcjSHDldh6OMsND/dXeEQPJsh7OBGekeZRDyaaWXu6eHrDeEU60wjgpsJuRPrgaV4 iZ7TavwRvE8GfiNo9msRS3qviEtLCC31o31pww//tLlQ3sxbts6wJkT2LMUTD1JHwTtL xhGw==
X-Gm-Message-State: APf1xPCAP3NdbwYabraPzqF1qNE7rOTXa8zuM6SIduHhtVBHOkiep3HP sSzRT0Q/MuLm7OQIIVVf4pyn40GhORV/gTHFbjY=
X-Google-Smtp-Source: AH8x225mXMrcGlFxC/A/g6scJsOn748l1IZJfWjUq5olvWG8RdJV1uXTmKWBRm0/piAgxvDsdpCrXRL+9mgv2c1ZcuA=
X-Received: by 10.31.171.5 with SMTP id u5mr4177352vke.120.1518967685037; Sun, 18 Feb 2018 07:28:05 -0800 (PST)
MIME-Version: 1.0
Received: by 10.176.10.24 with HTTP; Sun, 18 Feb 2018 07:27:44 -0800 (PST)
In-Reply-To: <5c33acfd-8853-4254-c6b1-fa05ea4901fd@omnitor.se>
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>
From: Bernard Aboba <bernard.aboba@gmail.com>
Date: Sun, 18 Feb 2018 10:27:44 -0500
Message-ID: <CAOW+2dvuAjON1+pi2renF+fD4qYMpUhq5zPDhF9EdepHO8X18g@mail.gmail.com>
To: =?UTF-8?Q?Gunnar_Hellstr=C3=B6m?= <gunnar.hellstrom@omnitor.se>
Cc: Randall Gellens <rg+ietf@randy.pensive.org>, slim@ietf.org
Content-Type: multipart/alternative; boundary="001a114408424ac4e505657e3952"
Archived-At: <https://mailarchive.ietf.org/arch/msg/slim/fb4Ox_FxChSa-75_idqv9Itq0Vg>
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: Sun, 18 Feb 2018 15:28:09 -0000

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
>> Omnitorgunnar.hellstrom@omnitor.se
>> +46 708 204 288
>>
>>
>
> --Randall
>
>
> _______________________________________________
> SLIM mailing listSLIM@ietf.orghttps://www.ietf.org/mailman/listinfo/slim
>
>
> --
> -----------------------------------------
> Gunnar Hellström
> Omnitorgunnar.hellstrom@omnitor.se
> +46 708 204 288
>
>