Re: [Ietf-languages] [EXTERNAL] Re: language identifiers for sign languages (incl. sgn) vs. attribute for indicating the representation of an individual language in "sign language modality"

John Cowan <cowan@ccil.org> Sun, 24 November 2019 17:05 UTC

Return-Path: <cowan@ccil.org>
X-Original-To: ietf-languages@ietfa.amsl.com
Delivered-To: ietf-languages@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id C9E48120058 for <ietf-languages@ietfa.amsl.com>; Sun, 24 Nov 2019 09:05:22 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -3.532
X-Spam-Level:
X-Spam-Status: No, score=-3.532 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_SOFTFAIL=0.665, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=ccil-org.20150623.gappssmtp.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 Fedstr5wSm_e for <ietf-languages@ietfa.amsl.com>; Sun, 24 Nov 2019 09:05:20 -0800 (PST)
Received: from mork.alvestrand.no (mork.alvestrand.no [158.38.152.117]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 44C7B12001E for <ietf-languages@ietf.org>; Sun, 24 Nov 2019 09:05:20 -0800 (PST)
Received: by mork.alvestrand.no (Postfix) id 6578A7C0A21; Sun, 24 Nov 2019 18:05:16 +0100 (CET)
Delivered-To: ietf-languages@alvestrand.no
Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id 4EDDE7C08C3 for <ietf-languages@alvestrand.no>; Sun, 24 Nov 2019 18:05:16 +0100 (CET)
X-Virus-Scanned: Debian amavisd-new at alvestrand.no
Authentication-Results: mork.alvestrand.no (amavisd-new); dkim=pass (2048-bit key) header.d=ccil-org.20150623.gappssmtp.com
Received: from mork.alvestrand.no ([127.0.0.1]) by localhost (mork.alvestrand.no [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id sDz9-dn3HP9V for <ietf-languages@alvestrand.no>; Sun, 24 Nov 2019 18:05:12 +0100 (CET)
X-Greylist: from auto-whitelisted by SQLgrey-1.8.0
X-Greylist: from auto-whitelisted by SQLgrey-1.8.0
X-Comment: SPF skipped for whitelisted relay - client-ip=192.0.46.74; helo=pechora8.dc.icann.org; envelope-from=cowan@ccil.org; receiver=ietf-languages@alvestrand.no
Received: from pechora8.dc.icann.org (pechora8.icann.org [192.0.46.74]) by mork.alvestrand.no (Postfix) with ESMTPS id 224877C060A for <ietf-languages@alvestrand.no>; Sun, 24 Nov 2019 18:05:11 +0100 (CET)
Received: from mail-qk1-x72c.google.com (mail-qk1-x72c.google.com [IPv6:2607:f8b0:4864:20::72c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by pechora8.dc.icann.org (Postfix) with ESMTPS id A19B0C08CD for <ietf-languages@iana.org>; Sun, 24 Nov 2019 17:05:10 +0000 (UTC)
Received: by mail-qk1-x72c.google.com with SMTP id c124so6245778qkg.0 for <ietf-languages@iana.org>; Sun, 24 Nov 2019 09:05:10 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ccil-org.20150623.gappssmtp.com; s=20150623; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=IloCvcVsGkcEpk66TDJ0fyYLGBYJoDjrLLZFneOsmMk=; b=0hh6wK567qQP+dN23nM9DGC8E4ydzLl9HK26+liQsiQb9EBzzQJrmLQ1PO4sL4NJva QyleIu/wL3XZ8R75vrKt3bVUIygLE7xrKwR84GEUqio1QEgNSleWwPjptVBZnkWYnJik Nbsr9+lZnmSB2tLhCIRTrijN22MoEg2IXoxzqqhw/AT/v2idp9wTgJV/WquPC0NN5w2n H9DbRSsgfjcDYYId9z/oGgn10pDgTVdSV/fyMmsYCbFtoCzeSHJYHaCv47YcuI5oeILi nhywsG03E0Z8TXvmvooPkdWPADcd1xNZFKtsYJYsToI7OpbUysfQstWexTlgeIbuUFMQ DDCg==
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=IloCvcVsGkcEpk66TDJ0fyYLGBYJoDjrLLZFneOsmMk=; b=PLsncItEf5iunwUFfKvtvs+0MIgKFRJf6wXYg9mBf29HI5LzklOd77kOtzNJlxpyjr fj4prII0gRi4QgUWUooaHs8nikj0XAQ+tXxs66ArOHWaGKF7rWHJVtx7+0hpcz/0Uknn rzqtlZ8hXrJIOAHYj7TDrJNdhLR2KToK3c4VH0PjKbJkIus9EJovPckgze3WZxCgtOKX ovVQrt2HDh+90C8if9Q3ixfrYkmhDk4tidCx5oRd6fCkzV1QgAgO3LMjfPKoDN3PaLT3 b4u4APy7nDU3QoMsbrFUcwDR0keSAsx0JTkfkvhEM5cttkR4gInWL9q7QTVs56Tyrzo4 YOVg==
X-Gm-Message-State: APjAAAV0ZCIBgr2LkAfpPt9v0WaIbuZ72RAfMoqZeCQ27lv1Pi3Ovw55 cbkdmDn6swCJdVP2/JXIe6vw6bMTb6PgHLmh62/0Fg==
X-Google-Smtp-Source: APXvYqxFH2/r51LA2wuxLfl7e4q+JuqTCIxZv9YjqwZltxk5K1l3Q1kj6yGfFTeg3VcstGALncwJbcLHCPph5bxtfPQ=
X-Received: by 2002:a37:68a:: with SMTP id 132mr23188852qkg.359.1574615090101; Sun, 24 Nov 2019 09:04:50 -0800 (PST)
MIME-Version: 1.0
References: <20191122140445.665a7a7059d7ee80bb4d670165c8327d.e5d7554235.wbe@email03.godaddy.com> <MW2PR2101MB10651AA60FBA508E53BE023BD5480@MW2PR2101MB1065.namprd21.prod.outlook.com> <YTXPR0101MB0861EBEA60D89A2846BCC6B685480@YTXPR0101MB0861.CANPRD01.PROD.OUTLOOK.COM> <003001d5a223$241a34f0$6c4e9ed0$@chello.at>
In-Reply-To: <003001d5a223$241a34f0$6c4e9ed0$@chello.at>
From: John Cowan <cowan@ccil.org>
Date: Sun, 24 Nov 2019 12:04:39 -0500
Message-ID: <CAD2gp_QOT+bWOqdAcxB_WXQKpePuFOXcNnBgD2aOEFvOqHYEmA@mail.gmail.com>
To: Christian Galinski <christian.galinski@chello.at>
Cc: "Fourney, David" <david.fourney@usask.ca>, Peter Constable <petercon@microsoft.com>, Doug Ewell <doug@ewellic.org>, jzag@loc.gov, Debra Russell <drussell@ualberta.ca>, ietf-languages <ietf-languages@iana.org>, Sebastian Drude <Sebastian.Drude@outlook.com>, Melinda Lyons <Melinda_Lyons@sil.org>, Gary Simons <gary_simons@sil.org>, "105-5-03 Hein, Anja" <105-5-03@auswaertiges-amt.de>
Content-Type: multipart/alternative; boundary="0000000000001a94f205981aa582"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf-languages/x3Tf2IiHSAmHqHumhmyfZYWkg7o>
X-Mailman-Approved-At: Sun, 24 Nov 2019 15:04:29 -0800
Subject: Re: [Ietf-languages] [EXTERNAL] Re: language identifiers for sign languages (incl. sgn) vs. attribute for indicating the representation of an individual language in "sign language modality"
X-BeenThere: ietf-languages@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: <ietf-languages.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ietf-languages>, <mailto:ietf-languages-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/ietf-languages/>
List-Post: <mailto:ietf-languages@ietf.org>
List-Help: <mailto:ietf-languages-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ietf-languages>, <mailto:ietf-languages-request@ietf.org?subject=subscribe>
X-List-Received-Date: Sun, 24 Nov 2019 17:05:23 -0000

On Sat, Nov 23, 2019 at 12:26 PM Christian Galinski <
christian.galinski@chello.at> wrote:


>    1. “sgn” standing alone (similar to an individual language) would
>       continue to mean unknown individual sign language or a signed language
>       variety, such as fingerspelling etc. of an unspecified individual language
>
>
That seems a bit of a stretch.  'Sgn' is an ISO 639-5 code and as such
represents a collection of languages; thus 'ase' is a member of 'sgn'
whether it is signed or written, but 'eng' would not be understood as a
member of 'sgn' even if signed.  Wisely, ISO 639-5 abstains from
enumerating the languages which fall into each of its collections, since
membership in most of them is dependent on scholarship, which is inherently
unstable. Though such minor violations of tagging principles are routine, I
would not like to see this elevated into a principle itself.


>
>    1.
>       2. “sgn” attributed to a language identifier of an individual
>       language (not being a sign language) could indicate one or the other kind
>       of “signed language variety” – e.g. (in ISO 639) “eng-sgn” = English in
>       signed language variety and – if differentiation necessary – “eng-UK-sgn”
>       British English in signed language variety
>       3. “sgn” attributed to a language identifier of an “individual sign
>       language” could be used to make individual sign languages
>       identifiable and searchable – e.g. (in ISO 639) “ase-sgn” =
>       American Sign Language (ASL) and – if differentiation is necessary –
>       “ase-CA-sgn” Canadian variant of American Sign Language
>
>
I have strong objections to this on both process and principled grounds.

Historically, the meaning of particular codes has been the domain of the
various ISO 639 RAs (as well as the ISO 3166-1 MA and the ISO 15924 RA.
However, there is a strong de facto standard, IETF BCP 47, for the use of
these codes in combination.  ISO could assume responsibility for that code
combination standard.  But it would be quite another matter (and very
undesirable) for ISO to specify meanings for combined codes that
*contradicts* BCP 47.  Neither of your cases (b) and (c) is conformant with
either the syntax or the principles of BCP 47.

In particular, one of those principles is that BCP 47 tags label rather
than classifying.  There are exceptions to this, but most of them exist for
historical reasons.  Thus the combined codes "sgn-ase" and "sgn-US" both
represent ASL, and may be suitable in particular circumstances; but the
preferred method is to use simply "ase" without combination.  The knowledge
that ASL is a sign language (i.e. it belongs to the "sgn" collection)  is
not determinable from the code alone, any more than the knowledge that
English is a Germanic language (i.e. it belongs to the "ger" collection)
and is generally written in the Latin script can be determined from the
code alone.


>    1.
>
>
>    1. As there seems to be a need for much more refined differentiations,
>    codes for such “sgn” varieties could be added in an additional code-slot;
>    the maintenance of these codes would need to be taken care of by the
>    respective stakeholders, but – if possible/desired – coordinated with the
>    ISO 639 maintenance rules and procedures.
>    2. If the need for other kinds of language modalities arises
>    (considering the whole range of full individual languages to (drummed,
>    whistled, haptic etc.) modalities of any identified individual language),
>    it would need an attribute that can probably be used in code combinations
>    in the slot foreseen for “sgn”. Here too then, codes for varieties of such
>    modalities could be added in an additional slot. Should such a code for an
>    attribute for language modalities be considered already now or be left for
>    the future?
>
> My points made above also apply here.



John Cowan          http://vrici.lojban.org/~cowan        cowan@ccil.org
Dievas dave dantis; Dievas duos duonos        --Lithuanian proverb
Deus dedit dentes; deus dabit panem           --Latin version thereof
Deity donated dentition;
  deity'll donate doughnuts                   --English version by Muke
Tever
God gave gums; God'll give granary            --Version by Mat McVeagh