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 23:44 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 A1C601200CE for <ietf-languages@ietfa.amsl.com>; Sun, 24 Nov 2019 15:44:58 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.021
X-Spam-Level:
X-Spam-Status: No, score=-1.021 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, HTML_FONT_FACE_BAD=0.001, HTML_MESSAGE=0.001, HTTPS_HTTP_MISMATCH=0.1, SPF_HELO_NONE=0.001, SPF_SOFTFAIL=0.665, T_KAM_HTML_FONT_INVALID=0.01, URIBL_BLOCKED=0.001, URI_HEX=0.1] autolearn=no 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 lwAnCPTT9Dpd for <ietf-languages@ietfa.amsl.com>; Sun, 24 Nov 2019 15:44:55 -0800 (PST)
Received: from mork.alvestrand.no (mork.alvestrand.no [IPv6:2001:700:1:2::117]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 5FEAA12001E for <ietf-languages@ietf.org>; Sun, 24 Nov 2019 15:44:54 -0800 (PST)
Received: by mork.alvestrand.no (Postfix) id 4D47E7C0A21; Mon, 25 Nov 2019 00:44:52 +0100 (CET)
Delivered-To: ietf-languages@alvestrand.no
Received: from localhost (localhost [127.0.0.1]) by mork.alvestrand.no (Postfix) with ESMTP id 36ADF7C0A20 for <ietf-languages@alvestrand.no>; Mon, 25 Nov 2019 00:44:52 +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 iuCMErqnI513 for <ietf-languages@alvestrand.no>; Mon, 25 Nov 2019 00:44:45 +0100 (CET)
X-Greylist: delayed 00:05:05 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.33.71; helo=pechora1.lax.icann.org; envelope-from=cowan@ccil.org; receiver=ietf-languages@alvestrand.no
Received: from pechora1.lax.icann.org (pechora1.icann.org [192.0.33.71]) by mork.alvestrand.no (Postfix) with ESMTPS id 67E037C08C3 for <ietf-languages@alvestrand.no>; Mon, 25 Nov 2019 00:44:43 +0100 (CET)
Received: from mail-qt1-x832.google.com (mail-qt1-x832.google.com [IPv6:2607:f8b0:4864:20::832]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by pechora1.lax.icann.org (Postfix) with ESMTPS id B0C871E0322 for <ietf-languages@iana.org>; Sun, 24 Nov 2019 23:39:34 +0000 (UTC)
Received: by mail-qt1-x832.google.com with SMTP id 30so15143398qtz.12 for <ietf-languages@iana.org>; Sun, 24 Nov 2019 15:39:34 -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=0LNvKTdaSFnzLbwB3MdTxjzZyIq/HqsFpb20gPjgnF0=; b=vDaYnuIovpwHhwYhCq1+hzcvynoZ5vJ7cldmU/WZjDS/2bNWqejryMm4cP95V4je5s EIjLqbCFE+eV36279+J3V90cfIS3ANpcOW9ilvCKyW/P4aeRP0ccXdptG7ci2hw3Y7ay rTvU0QOcj7cjwEw4WGu2AGSzpK10QFXugM39sih46S1er1JWa6bH3fRdsoTfNCuj2cS0 vkeOp7C8BPvpAnhlSjITU0NCK/jSPcoRijNXaLVRmy6qOXThdLJKXWSf85pN0nQSS9GK Go45ptNkcNRW3Em/IDfhQ6ErdKBfCf7PqqqcJ/t1C2P8RNsj7/WVs9364+zpwe4ujjYB dGkA==
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=0LNvKTdaSFnzLbwB3MdTxjzZyIq/HqsFpb20gPjgnF0=; b=h0yYrkgY1onOAb3MfjemzB5CSJcjLTezUl16GZcEqA6lUHbRW3YUJrrrMGxk8uqkjP iswwQoh0Z9c+yApF1KJzp8xVSAmqtP0sHLXSr5iwpqyQ7cYxvfEbR9Vct48PzHx17q0H Drt28H8xFHbinKJSg3gjHbVdb5nfTx8rD2ADmDLPHwK2rVvYdn4QXwGWNMzpXJS5jDOP qve0y/+UiB8l/DVrvOknU6MtvDug49tv0M7+4vQ2xtCfsI+M8C/R/PHWBZlJKn+wX9F0 HNuk0ZYn/2YCDey/LX8fM4/6I7dO6lvtnL4W2FBcgyrxGTXbmT4UGyEdfx8FGomWSRjT FCjQ==
X-Gm-Message-State: APjAAAVXTEI2mibtZ1DRHLxVt6ktvuVCdIPu4U20+LaetqdNCyJoi3Nu 3BIED8U/7Fcmhy9qjV5BZH+WYU/R47bhR6y65ELi9T4pL08=
X-Google-Smtp-Source: APXvYqy9YK9oiz9iQV8HIpkcqG5pTNmFyGJtPS7wcldJYkAKYp2GwF4k/lJJyngSWQIeP53Y25f/NnL557MzcnyAIsE=
X-Received: by 2002:ac8:2903:: with SMTP id y3mr25150720qty.83.1574638753595; Sun, 24 Nov 2019 15:39:13 -0800 (PST)
MIME-Version: 1.0
References: <20191122140445.665a7a7059d7ee80bb4d670165c8327d.e5d7554235.wbe@email03.godaddy.com> <MW2PR2101MB10651AA60FBA508E53BE023BD5480@MW2PR2101MB1065.namprd21.prod.outlook.com> <CAD2gp_RjCHQuyvBm9mTt44uc8Ge7DNGxvKnL1V1xb-pnSXXokA@mail.gmail.com> <CAJ2xs_GxsWq4CDEmDqfFKcjHiHXPtU9m-Bxa6yh0=EqJ_5ya3Q@mail.gmail.com>
In-Reply-To: <CAJ2xs_GxsWq4CDEmDqfFKcjHiHXPtU9m-Bxa6yh0=EqJ_5ya3Q@mail.gmail.com>
From: John Cowan <cowan@ccil.org>
Date: Sun, 24 Nov 2019 18:39:03 -0500
Message-ID: <CAD2gp_T39M5e4MQm+SOXTZfaD6D=kQDq5NF8RX_xMbc+UT02Bg@mail.gmail.com>
To: ietf-languages <ietf-languages@iana.org>
Cc: Christian Galinski <christian.galinski@chello.at>, "Fourney, David" <david.fourney@usask.ca>, Sebastian Drude <Sebastian.Drude@outlook.com>, "Melinda_Lyons@sil.org" <Melinda_Lyons@sil.org>
Content-Type: multipart/alternative; boundary="0000000000008ed623059820274a"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf-languages/9VUcU6ZWPI59uT_RcMMuVuHhoJw>
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 23:44:59 -0000

On Sun, Nov 24, 2019 at 4:14 PM Mark Davis ☕️ <mark@macchiato.com> wrote:

It would be far better have a useful generative mechanism, instead of
> hundreds of combinations mashed together. Why not just: "it-signed" ? If
> the variant 'signed' is defined, every parser immediately knows that it is
> a signed variant, and doesn't have to look up the meaning of an obscure
> combination of codes.  It can be used with *any* language (optionally plus
> region, optionally plus subdivision, as necessary), and correctly parsed.
>

Y'know, it's not like I didn't think of that already.  But:

it-signed: useless (could be any of three not mutually intelligible systems)
it-IT-signed: still useless (two systems)
en-signed: useless (at least 13 systems)
en-US-signed: useless (at least 6 systems)

The minute it matters whether someone can understand the conventions in
use, variant subtags are needed.  I am not of course proposing that we
create these variants en masse, any more than we do with other variant
subtags, but just as-needed.

What is more, systems cannot assume that something with neither 'sgn' nor
'signed'' can be assumed not to be signed:  "ads" implicitly has signed
modality, for example.  Facts about languages ought to be maintained in a
knowledge base, not in the tag: as I said, tags label languages and their
variants, they do not classify them, except very partially.

Generativeness is good for figuring how to invent tags, not for how to use
them, and I am proposing a partially generative framework.  Yes, people
will have to ask for them, just as they have to ask for regionalects or
orthographies or anything else today.  Compared to, say, the Unicode
character approval process, our process for approving variant subtags (once
the proposal is in shape) is about 50 times faster.  I don't see what there
is to complain about.


Data source:  https://en.wikipedia.org/wiki/Manually_coded_English and
https://en.wikipedia.org/wiki/Manually_coded_language

John Cowan          http://vrici.lojban.org/~cowan        cowan@ccil.org
Dream projects long deferred usually bite the wax tadpole.
        --James Lileks




> Moreover, there is then no necessity for people to go cap in hand to
> petition for a new code. Once 'signed' is defined, then if someone wants a
> code to use "tk-AF-signed" for sign language associated with Turkmen as
> used in Afghanistan, or even "tk-signed-u-sd-afkdz" for Turkmen as used in
> the Kunduz subdivision of Afghanistan, they are free to do so, without
> jumping through hoops.
>
> There can of course be additional variants added as necessary if there are
> multiple systems that can't be distinguished by
> language+region+subdivision. But it would only be need to be defined in
> such cases.
>
> Mark
>
>
> On Sat, Nov 23, 2019 at 3:10 AM John Cowan <cowan@ccil.org> wrote:
>
>> I agree that the 't' subtag is not suitable, but I don't think a generic
>> '-signed-' subtag is a good idea either.  I think we have to use registered
>> variant tags, and I propose the following convention for them:
>>
>>         lexifier language tag (3 letters) + disamiguator (2-5 letters or
>> digits).
>>
>> Note that this is a single tag, and you can't tell by looking at it if it
>> is for a signed modality or not.
>>
>> Examples (shown with country subtags for clarity, but they could be
>> omitted):
>>
>> en-US-asefsp:  fingerspelled English using ASL letters
>> en-GB-bsifsp:  fingerspelled English using British Sign Language letters
>> en-US-asese: Bornstein's signed English (ASL content words, 14
>> grammatical particles)
>> en-US-asesee1: Seeing Essential English: ASL, modified ASL, and novel
>> signs
>> pl-PL-psosee1: Seeing Essential Polish (like asesee1, but lexified by
>> Polish Sign)
>> en-US-asesee2: Signing Exact English: variant of asesse1 that uses
>> additional ASL signs for some English compound words; also used in SG
>> en-GB-bsise: British Signed English, conceptually similar to asesee1 but
>> not derived from it
>> en-GB-bsisse: Sign-Supported English, uses mouthing to distinguish
>> between English words represented by the same sign in British Sign
>> en-GB-pagetgor: Paget-Gorman Sign, all lexemes are artificial
>> en-asf: mostly Auslan signs with some from ASL, English syntax, used in
>> AU and NZ
>> en-IE-isgise: Irish Signed English (used in the republic)
>> en-UK-bsinisl: based on Northern Ireland dialect of British Sign (which
>> shares some syntax with Irish Sign)
>> fr-FR-fslfs: Français Signé lexified by French Sign
>> fr-BE-sfbfs: Français Signé lexified by French Belgian Sign
>> fr-CA-fcsfs: Français Signé lexified by Québec Sign
>> de-gsglbg: Deutsche Gebärdensprache, used in DE and BE
>> it-IT-iseis: italiano segnato
>> it-IT-iseise: italiano segnato essato
>>
>> And so on.
>>
>>
>> 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
>>
>>
>>
>>
>> On Fri, Nov 22, 2019 at 7:24 PM Peter Constable <petercon=
>> 40microsoft.com@dmarc.ietf.org> wrote:
>>
>>> The scope of the ‘t’ extension is linguistic content that has undergone
>>> some type of transform in its expression, and signed modality for a spoken
>>> language could be considered a transform. But the ‘t’ extension as
>>> currently defined doesn’t support this. What is supported is primarily
>>> dealing with text transformations. Also, the way the ‘t’ extension works is
>>> that the additional information declares what content was transformed _
>>> *from*_, not what it is transformed _*into*_. For signed modality of
>>> spoken languages, what’s needed is a way to indicate signed modality as the
>>> final expression, not the source.
>>>
>>>
>>>
>>> So, I don’t think the ‘t’ extension is appropriate.
>>>
>>>
>>>
>>> I think a variant subtag “signed” or “signmod” would be better. The main
>>> problem that would arise is that this is very generic (it could be usefully
>>> applied to any oral language), which there has been resistance to in the
>>> past. A smaller issue is that, while variant tags for specific
>>> signed-modality variants could be registered, it might make sense to use a
>>> subtag sequence along the lines -signed-modvarnt, but it’s currently not
>>> possible to specify a prefix as anything other than a valid language tag.
>>> (E.g., *-signed can’t be a prefix specification.) That wouldn’t be a
>>> problem as long as the signed-modality variant is specific to a particular
>>> language, as would be the case for (e.g.) Signed Exact English.
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> Peter
>>>
>>>
>>>
>>> *From:* Ietf-languages <ietf-languages-bounces@ietf.org> *On Behalf Of *Doug
>>> Ewell
>>> *Sent:* Friday, November 22, 2019 1:05 PM
>>> *To:* Christian Galinski <christian.galinski@chello.at>; 'Fourney,
>>> David' <david.fourney@usask.ca>
>>> *Cc:* ietf-languages <ietf-languages@iana.org>; 'Sebastian Drude' <
>>> Sebastian.Drude@outlook.com>; Melinda_Lyons@sil.org
>>> *Subject:* [EXTERNAL] Re: [Ietf-languages] language identifiers for
>>> sign languages (incl. sgn) vs. attribute for indicating the representation
>>> of an individual language in "sign language modality"
>>>
>>>
>>>
>>> Hi Christian,
>>>
>>>
>>>
>>> > Many true sign languages (se definitions below), such as “ase”
>>> > (American Sign Language [ASL], which /fictively/ might even have a
>>> > Newfoundland and Labrador variety – to be coded ase-CA-NL in line
>>> > with BCP47 rules) have already a language identifier.
>>>
>>>
>>>
>>> This example is actually not valid BCP 47 syntax. The use of ISO 3166-1
>>> country codes as region subtags doesn't extend to appending ISO 3166-2
>>> subdivision codes directly. You would need to use "ase-u-sd-canl" or
>>> "ase-CA-u-sd-canl". See UTS #35, Section 3.6.5.
>>>
>>>
>>>
>>> > The question to Doug is, how the BCP and Unicode rules deal with the
>>> > above-mentioned difference between (true) “individual sign languages”
>>> > and the “signed language modality” (as a sort of “transform” of any
>>> > individual language)?
>>>
>>>
>>>
>>> I don't believe there are or should be any "Unicode rules" (which I
>>> assume refers to CLDR and the 't' or 'u' extension) that deal with this.
>>>
>>>
>>>
>>> One approach would be to request a variant subtag, such as 'signed', to
>>> represent the signed modality of a spoken language, such as (but not
>>> limited to) Signing Exact English. See RFC 5646, Section 2.2.5 for details
>>> on variant subtags and Section 3.6 for details on requesting a registration.
>>>
>>>
>>>
>>> However, some may argue that modality is beyond the scope of BCP 47
>>> variants and would suggest a CLDR extension to deal with this within the
>>> 't' extension framework. In that case, your best bet would be to contact
>>> cldr-contact@unicode.org .
>>>
>>>
>>>
>>> --
>>> Doug Ewell | Thornton, CO, US | ewellic.org
>>> <https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fewellic.org&data=02%7C01%7Cpetercon%40microsoft.com%7C19558599ac7d421157fc08d76f8fc274%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637100535555481188&sdata=5sWZ089qfuVRPWbmetKrFDHskz%2BETA2vY0ioACdSzos%3D&reserved=0>
>>>
>>>
>>>
>>>
>>>
>>> -------- Original Message --------
>>> Subject: language identifiers for sign languages (incl. sgn) vs.
>>> attribute for indicating the representation of an individual language in
>>> "sign language modality"
>>> From: "Christian Galinski" <christian.galinski@chello.at>
>>> Date: Fri, November 22, 2019 11:48 am
>>> To: "'Fourney, David'" <david.fourney@usask.ca>
>>> Cc: <Melinda_Lyons@sil.org>, "'Sebastian Drude'"
>>> <Sebastian.Drude@outlook.com>, <doug@ewellic.org>
>>>
>>>
>>> Dear David,
>>>
>>>
>>>
>>> First I have to apologize for my long silence – I was absorbed with work
>>> on several standards.
>>>
>>>
>>>
>>> We are now at a crucial moment where things need to be clarified in ISO
>>> 639-4 “language coding” (and ISO/TR 21636 “Language varieties”) – including
>>> your issue of how to identify “individual sign languages” (i.e. true
>>> individual sign languages, which are not just a modality of spoken
>>> language) and the “signed language modality” which is a signed
>>> representation of a spoken language).
>>>
>>>
>>>
>>>    1. concerning the difference between “individual sign languages” and
>>>    “signed language modality”, the use of the language identifier “sgn” (in
>>>    library use) is confined to an unidentifiable *individual sign
>>>    language* – it is NOT referring to a “signed language modality”.
>>>    According to the fundamental rules of language coding, we cannot change the
>>>    scope of “sgn”, nor ignore the difference between sign language and the
>>>    signed language modality.
>>>    Therefore, for the *sign language modality* we need an “attribute”
>>>    to be added to the language identifier of an individual language, e.g. if
>>>    the sign language modality of the type of “Signing Exact English” is used.
>>>    2. However, I could not find an identifier for *signed language
>>>    modality*, nor a mechanism for inserting an identifier for this in:
>>>
>>> *https://tools.ietf.org/html/bcp47*
>>> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fbcp47&data=02%7C01%7Cpetercon%40microsoft.com%7C19558599ac7d421157fc08d76f8fc274%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637100535555486190&sdata=PWlDE0pdRCgLBG4wsnprwit5%2B6EeB%2Fux%2FiApkJkmweg%3D&reserved=0>
>>>
>>> *https://tools.ietf.org/html/rfc6497#ref-UTS35*
>>> <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Frfc6497%23ref-UTS35&data=02%7C01%7Cpetercon%40microsoft.com%7C19558599ac7d421157fc08d76f8fc274%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637100535555491183&sdata=Y3Zi1erRIWT%2F8K%2F5ZhtfSPCofmTkczyny89RagNWmhA%3D&reserved=0>
>>>
>>> *http://unicode.org/reports/tr35/*
>>> <https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Funicode.org%2Freports%2Ftr35%2F&data=02%7C01%7Cpetercon%40microsoft.com%7C19558599ac7d421157fc08d76f8fc274%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637100535555496180&sdata=fezBI46al7DmxtciBBIwI7Fj%2Fuuyor7d8uB7xdyvzM4%3D&reserved=0>
>>>
>>> The regular order of attributes to a language tag (language identifier)
>>> is “lang-geogr” (dialect), or “lang-script” (language written in a certain
>>> script) or “lang-script-geogr” (language in a script in a certain region)..
>>> In between, a “t” (for “transform” in the meaning of transcription,
>>> transliteration, translation or other) may be inserted.
>>>
>>>
>>>
>>> From your experience/problems with video technology (and HTML), the
>>> questions to you would be:
>>>
>>>    1. Many true sign languages (se definitions below), such as “ase”
>>>    (American Sign Language [ASL], which /fictively/ might even have a
>>>    Newfoundland and Labrador variety – to be coded ase-CA-NL in line with
>>>    BCP47 rules) have already a language identifier.
>>>    *Does it need another attribute to further specify them as a sign
>>>    language? *In that case, an attribute must be found which is
>>>    different from “sgn”. How could it look like?
>>>    2. In the case of a *signed language modality*, such as “Signing
>>>    Exact English” the core language identifier for English would be “eng”. It
>>>    would need an attribute to identify it as the signed language modality
>>>    (which could be followed by a country code, if there are “dialects” of /fictive/
>>>    eng-xxx-AUS meaning “Signing Exact English as used in Australia”.
>>>    What could “xxx” indicating “signed language modality look like?
>>>    3. It probably would not help to use an attribute identifier “Xxxx”
>>>    in the slot of “script code”, as a signed language modality might slightly
>>>    differ depending on the script used, even if it is the same spoken language
>>>    (represented in different scripts in different areas/communities).
>>>    4. Could the “t” (transform) symbol be of help – as a given signed
>>>    language modality somehow is a “transformation” of a spoken language?
>>>
>>>
>>>
>>>    1. The above questions (resp. the answer to them) could have an
>>>    impact on ISO 639 and ISO/TR 21636 insofar as we should not formulate
>>>    provisions in these documents which conflict with other standards. We
>>>    should rather try to find generic solutions.
>>>
>>>
>>>
>>> The question to Doug is, how the BCP and Unicode rules deal with the
>>> above-mentioned difference between (true) “individual sign languages” and
>>> the “signed language modality” (as a sort of “transform” of any individual
>>> language)? see the respective terminology entries below
>>>
>>>
>>>
>>> Best regards
>>>
>>> Christian
>>>
>>>
>>>
>>>
>>>
>>> p.s.
>>>
>>> In the most recent revised version of ISO 639-4 we came up with the
>>> following terminology entries:
>>>
>>> individual sign language
>>>
>>> NOT: signed language
>>>
>>> *individual language* (3.1.3) having the visual-spatial *language
>>> modality* (3.5.1) as basic modality
>>>
>>> Note 1 to entry: Usually “sign language” appears as part of the name of
>>> the respective individual language.
>>>
>>> EXAMPLE: ASL (American Sign Language); )
>>>
>>>
>>>
>>> signed language modality
>>>
>>> NOT: sign language
>>>
>>> visual-spatial *language modality* (3.5.1) that uses a combination of
>>> hand shapes, palm orientation and movement of the hand, arm or body, and
>>> facial expression
>>>
>>>
>>>
>>> _______________________________________________
>>> Ietf-languages mailing list
>>> Ietf-languages@ietf.org
>>> https://www.ietf.org/mailman/listinfo/ietf-languages
>>>
>> _______________________________________________
>> Ietf-languages mailing list
>> Ietf-languages@ietf.org
>> https://www.ietf.org/mailman/listinfo/ietf-languages
>>
>