Re: [Slim] Moving forward on draft-ietf-slim-negotiating-human-language

Bernard Aboba <> Sun, 19 November 2017 17:27 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id DEFFC127011 for <>; Sun, 19 Nov 2017 09:27:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Status: No, score=-1.998 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, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id cnfqJo8kY1wJ for <>; Sun, 19 Nov 2017 09:27:48 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:400e:c05::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 54E001200E5 for <>; Sun, 19 Nov 2017 09:27:48 -0800 (PST)
Received: by with SMTP id 70so5543914pgf.6 for <>; Sun, 19 Nov 2017 09:27:48 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=eWoLohJIRbaYaQKMGCLwTCbZzVDvX0Hc9kVNyiAJJmc=; b=KNqk2mzFbqw+GF6cJRHj+4N19oWZlyivDHUB6rIgBxyWEK1XIyqDOVlrz0m1BBdrUd F7FSExKdvRKmz3R/F0J1Hg4DdZt5V+3lEvdUKPPk37P/QZ1x8CrOpRs8Eex+INzpy6jn fOkeb4Cz4mj6oqKUGV1LE2S9CtJWqaQ/df+C8XWi/NEyz6lyonVU/fDFDUyi73ou6jg2 EsuVLhUaV1r/nJ2BhN71VRJB6EzP96O4F770YLPW4e4mKR7760IG5DdZcQcG69/QScqc Eo0Grd1FzAzppFepQo5xjpYKzZyiZ6f7nog0Q2fMegKovMVk4WDwWfWhL1E5K8RurcQ9 cOPg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=eWoLohJIRbaYaQKMGCLwTCbZzVDvX0Hc9kVNyiAJJmc=; b=rJNYYvK2gquM/RRgfld9VYaKylfZ7skWu+6av7dOcDl3xR/ZlKd25+L3P7jNUldunu frd95xIzotzo+dFPAS8sUGTSp5dlAoDPxhBsVVhODBu4EudPXeXroZ83ZAU8KOAllHsE +UzQNt8tMjYSJslrEkskMt2eGStZie7ifYdxY8soMYKCqMa21byvg7fuR1QlqKC01eR4 Hj0x38tDxF3JQCUUmTTZYujumKVrmNYlwWN/73he+P9OBmH32fk5kAOBJU6YPC+XrOJI d/zmIft766HFdE8RHE9gAQDRGHnewAmmnlejNb76ZvAFlI1g8TFoHln6LgtbE/bkLwdy Csnw==
X-Gm-Message-State: AJaThX4696rh3potvjul5KYp2YCqe/EJnx2FYYrV16TgAeTFJiO0wL2G 1PsML3cHj9e/lX2Frygu0QKpkSrf
X-Google-Smtp-Source: AGs4zMYvZg3fjf15KZhjDhG/xCcxtDuNzdNDhomi4Ws2F6WDA6X8Nv+ZnO9GpZX9in6ex3y439ZRhg==
X-Received: by with SMTP id a2mr10891591pgn.157.1511112467192; Sun, 19 Nov 2017 09:27:47 -0800 (PST)
Received: from [] ( []) by with ESMTPSA id o88sm15541022pfj.175.2017. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 19 Nov 2017 09:27:46 -0800 (PST)
Content-Type: multipart/alternative; boundary=Apple-Mail-B06DE79F-4AB8-4752-BE20-F4C156C1F7EE
Mime-Version: 1.0 (1.0)
From: Bernard Aboba <>
X-Mailer: iPhone Mail (15B150)
In-Reply-To: <>
Date: Sun, 19 Nov 2017 09:27:45 -0800
Content-Transfer-Encoding: 7bit
Message-Id: <>
References: <> <> <> <>
To: =?utf-8?Q?Gunnar_Hellstr=C3=B6m?= <>
Archived-At: <>
Subject: Re: [Slim] Moving forward on draft-ietf-slim-negotiating-human-language
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: Selection of Language for Internet Media <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Sun, 19 Nov 2017 17:27:50 -0000

On Nov 19, 2017, at 2:40 AM, Gunnar Hellström <> wrote:

>> <GH>Yes, it is a SHOULD. But all registered sign languages so
>>     far follow this rule, so I think it is solid. Do you think we need
>>     to weaken the start of our recommended procedure: 

[BA] As you say, it does appear that the rule is being followed. But perhaps we can find an expert to confirm this.

> <GH>Among the three obvious cases are also that sign languages in video media are signed.

[BA] Yes.

> <GH> The application must not create illogical combinations. But let us drop the "Content" attribute hint. I find the use of the script subtag much more solid for the otherwise ambiguous cases. RFC 5646 clearly says that it is allowed to use even suppressed script subtags when its use has an important discriminating meaning. (Section 4.1 of RFC 5646 says:
>        "The script subtag SHOULD NOT be used to form language tags unless
>        the script adds some distinguishing information to the tag."
> That is true for our case. 
> Can we explain our case better and get a go ahead from the language experts? That would result in a really simple set of rules. 

[BA] It seems like an important point to clarify.  Let me try to figure out how we can get expert consultation.