Re: [Slim] Alvaro Retana's No Objection on draft-ietf-slim-negotiating-human-language-19: (with COMMENT)

Bernard Aboba <bernard.aboba@gmail.com> Sun, 07 January 2018 02:51 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 05557126B6D for <slim@ietfa.amsl.com>; Sat, 6 Jan 2018 18:51:01 -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 Frnr4sjLTfzF for <slim@ietfa.amsl.com>; Sat, 6 Jan 2018 18:50:59 -0800 (PST)
Received: from mail-ua0-x234.google.com (mail-ua0-x234.google.com [IPv6:2607:f8b0:400c:c08::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 B581B126C22 for <slim@ietf.org>; Sat, 6 Jan 2018 18:50:58 -0800 (PST)
Received: by mail-ua0-x234.google.com with SMTP id v22so4857743uaj.1 for <slim@ietf.org>; Sat, 06 Jan 2018 18:50:58 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=4/yb+1wLoon/Jx1AIDD5YC81Pgt5s/oafCIHSrBEpbs=; b=O/HKToyjK+QS/4TKlrgVQixlEwJ1ZV3CdvWltLiPZJYAG0zWwWXP6344L/I4cjaL9K ju6bOTI2ZO9e4BGZxJ8o5AQYJH96rEb3r+nJHkD6pDowwje7GYM3j+MVCgIH/iguznGc qjRcy2dNX42ON/T4c9uJ3ACmTYLCMK6nd/7P1f3gSUkImHP5rq0rxK7zrIIYxJSQe8+N 0LHcN8gtrY5Ui1/GSJep4WVs2go23Go1OSOMw0zlcCDy7bJOlpnHf5KgGYwZvCdXZCcO rFJFzhON1NaLRbkfl6+Anbxkh/4rAvnZ7e18xmmxyzzRZG3xGLJ7QMYdYz24mus2wEif AdDw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=4/yb+1wLoon/Jx1AIDD5YC81Pgt5s/oafCIHSrBEpbs=; b=fDphsY+b0NRvEs+BTdGO9Q905GJ/VGXrYBzuctaNXMpWUv0ex81n7QUFCX7XchMYDy KorL1bplkzFpSnsIo/KAG3LGtEX1ws679Nen9D8ea7ZhL/rx7LDTNC6qvDpCU4R6w1wv 2P2Gr8ugiHqM9vQV3P3NMz10jf2tnP8x1v3A46ZM6o/l0Ef3tcUVJsT6m8+hTTL1RoN/ gW7rp1erY+VivApvSU0osIVTfkR0K9OrNzbDQzsal86+A2mzu+ZajBp8NMyvhpqFnsdv zcglNj/P8KBtoF7EQGOIJCwZE8puss/EVCQxM5CIKY6cmhB5T4DkDE/1Xhf6htwR/5JB QAPA==
X-Gm-Message-State: AKwxyte75nEOvNS1y/M7KccaL0wSf+5aWygAsTYbXl0G6lkquRaCvoz0 YDwPj+wIqNW+FkeAJqSye+yTQDIbo5+4xcae3SE=
X-Google-Smtp-Source: ACJfBoscgV3Z7kmuT3T+h0ZSBezCf+CgttbgOmrY73p6qW0jhZ7uHXeXtPcZHQqZIPRkVMK7iWeaWTYwngq9oE8lSc8=
X-Received: by 10.176.82.81 with SMTP id j17mr7357790uaa.202.1515293457511; Sat, 06 Jan 2018 18:50:57 -0800 (PST)
MIME-Version: 1.0
References: <151524801674.32303.11544137886906064260.idtracker@ietfa.amsl.com> <5e67b7a0-5527-12cc-f50a-74b8cbf832ef@alum.mit.edu>
In-Reply-To: <5e67b7a0-5527-12cc-f50a-74b8cbf832ef@alum.mit.edu>
From: Bernard Aboba <bernard.aboba@gmail.com>
Date: Sun, 07 Jan 2018 02:50:46 +0000
Message-ID: <CAOW+2duWovkiLuc3PgV436LGRvxubX5zL9O62XNmmJB=ViWC2A@mail.gmail.com>
To: =?UTF-8?Q?Gunnar_Hellstr=C3=B6m?= <gunnar.hellstrom@omnitor.se>, Paul Kyzivat <pkyzivat@alum.mit.edu>
Cc: slim@ietf.org
Content-Type: multipart/alternative; boundary="94eb2c191f1c43fa73056226c04f"
Archived-At: <https://mailarchive.ietf.org/arch/msg/slim/i4qALlXwRUuSNYMDQALVbVjywLE>
Subject: Re: [Slim] Alvaro Retana's No Objection on draft-ietf-slim-negotiating-human-language-19: (with COMMENT)
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, 07 Jan 2018 02:51:01 -0000

Paul said:

"I agree that this is really just some wisdom that is being encouraged, and
so should not be normative."

[BA] Agree that it should not be normative. However, the point about
subjectivity still applies. I’m not sure what value the SHOULD NOT
provides, even if it is in lower case.  For example, is it “difficult” to
ask to receive American English in audio but to send ASL in video or
American English in text, because the user is speech-impaired, but not
hearing-impaired?  Isn’t the whole point of the negotiation to determine
what languages can be mutually accommodated?

On Sat, Jan 6, 2018 at 6:51 AM, Paul Kyzivat <pkyzivat@alum.mit.edu> wrote:

> On 1/6/18 9:13 AM, Alvaro Retana wrote:
>
>> Alvaro Retana has entered the following ballot position for
>> draft-ietf-slim-negotiating-human-language-19: No Objection
>>
>> When responding, please keep the subject line intact and reply to all
>> email addresses included in the To and CC lines. (Feel free to cut this
>> introductory paragraph, however.)
>>
>>
>> Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
>> for more information about IESG DISCUSS and COMMENT positions.
>>
>>
>> The document, along with other ballot positions, can be found here:
>>
>> https://datatracker.ietf.org/doc/draft-ietf-slim-negotiating-human-language/
>>
>>
>>
>> ----------------------------------------------------------------------
>> COMMENT:
>> ----------------------------------------------------------------------
>>
>> Thanks for writing an interesting document!
>>
>> Given that this document doesn’t mandate the behavior in the case of not
>> having
>> languages in common, why does it matter if the combination is “difficult
>> to
>> match together” or not?  I’m wondering about this piece of text (from
>> 5.2):
>>
>>     ...The
>>     two SHOULD NOT be set to languages which are difficult to match
>>     together (e.g., specifying a desire to send audio in Hungarian and
>>     receive audio in Portuguese will make it difficult to successfully
>>     complete the call).
>>
>> I don’t understand how “difficult to match” can be enforced from a
>> normative
>> point of view.  Difficulty seems to be a subjective criteria -- the
>> example
>> shows a pair that I would consider difficult too (I don't speak
>> Hungarian!),
>> but other pairings could still be difficult for me but easy for others.
>> Using
>> “SHOULD NOT” (instead of “MUST NOT”) implies that there are cases in
>> which it
>> is ok to do it (again, probably subjectively).  It seems to me that the
>> “SHOULD
>> NOT” could be a simple “should not”.
>>
>
> I agree that this is really just some wisdom that is being encouraged, and
> so should not be normative.
>
>         Thanks,
>         Paul
>