IETF Logo Mail Archive

Re: [Ietf-languages] BCP47 violation in the recent extlang ajp change

Hugh Paterson III <sil.linguist@gmail.com> Tue, 28 March 2023 20:11 UTC

Return-Path: <sil.linguist@gmail.com>
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 D4622C1522C4 for <ietf-languages@ietfa.amsl.com>; Tue, 28 Mar 2023 13:11:00 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.093
X-Spam-Level:
X-Spam-Status: No, score=-2.093 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=0.001, RCVD_IN_ZEN_BLOCKED_OPENDNS=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001, URIBL_DBL_BLOCKED_OPENDNS=0.001, URIBL_ZEN_BLOCKED_OPENDNS=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 ([50.223.129.194]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id S_HgiPpj4E0N for <ietf-languages@ietfa.amsl.com>; Tue, 28 Mar 2023 13:10:56 -0700 (PDT)
Received: from mail-ed1-x535.google.com (mail-ed1-x535.google.com [IPv6:2a00:1450:4864:20::535]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id E9178C151549 for <ietf-languages@ietf.org>; Tue, 28 Mar 2023 13:10:56 -0700 (PDT)
Received: by mail-ed1-x535.google.com with SMTP id eg48so54406911edb.13 for <ietf-languages@ietf.org>; Tue, 28 Mar 2023 13:10:56 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; t=1680034255; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=2cN6ANoVtsjIwBrcsFkAEXHV3zZpx5WKyk3kpYaH4o0=; b=T706DZcq9+yWTWE6FvhsN2LBUBhLE5ZCQI4piLk1VayuQxCjWaEhBRGNnxsZSTSvrT 179t9bo8ZhrVXomqfqkDYD6V+/wfbge1O96ORf29XqicITEtAYErAC40J5kx6banJ31N 9iY5T4na6OfnNtehcwiHYjmUO6gcXbAO6ywKc6EquNQLglvnq46kfQFXlDuM0dIfB+pq m/jeSg92RF3l+sjUGl61+HfNJw5PWM20Q/MoYQbrB91n9xYBVHGd/aAy31XaC2LhcOk2 Gbl6Kx/XHCDQoF36jXFYUNKF01nYxULMy3H1of1vFuJ+Y9ILHl8VEykwieDMldplxr4a 6ACQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1680034255; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=2cN6ANoVtsjIwBrcsFkAEXHV3zZpx5WKyk3kpYaH4o0=; b=1ApUJrlXrC2IbtENFbLtVnvfgKp9qGmc13VV93oPkoO/4rn9crh86ptUnwUNQCbXQc 4OFZ6WEZXmlLuhtacCRLzDDPgghfIXd9aOZW4fIpL6v2E4NubhGrsxXBoPintnfW03Yi IAYFMQUew5Ea4m7QI9e20IfXSlZ/Dld17yLjMW9OhvS5TluFNqVWMdk1jKvIX6iCPgHO gVcEOLCp0MbczAaGARXBEd2JDvVhRaDNn/REMH9TkaWzrpOT7O4Z3f0kYXcNmxxEIL1g lZxciL40z2Jv9eeKHb3ezZVdPMUKvBhUJL2QveIa5bLNQHkG4VQG+MIr4vx6l6H/rSAc YTTA==
X-Gm-Message-State: AAQBX9dGa8boE7f4Co8brqhXOMm1il/rsJuQqf4LEQnYMF857kEl/O3+ nFZSmX/jQjwepXVNMTw7Fm5qCXPqG7bt64GOvGI=
X-Google-Smtp-Source: AKy350Y8h4E+kRpwfyKcO/8hj7dE4k6t4H4j0oMAhY9Zjzw5lSxFHWwK9fXgEri7fAGEFFm57PuwhQ7FyEw2gWSEd2E=
X-Received: by 2002:a05:6402:40ca:b0:502:3e65:44f7 with SMTP id z10-20020a05640240ca00b005023e6544f7mr7295765edb.3.1680034255205; Tue, 28 Mar 2023 13:10:55 -0700 (PDT)
MIME-Version: 1.0
References: <871qlbvbgo.fsf@gmail.com> <PH0PR03MB6606F4AFF9773C419EF09401CA8A9@PH0PR03MB6606.namprd03.prod.outlook.com> <7f1e4b72-fc25-bec8-9e36-cbffbdd6eeda@it.aoyama.ac.jp>
In-Reply-To: <7f1e4b72-fc25-bec8-9e36-cbffbdd6eeda@it.aoyama.ac.jp>
From: Hugh Paterson III <sil.linguist@gmail.com>
Date: Tue, 28 Mar 2023 13:10:43 -0700
Message-ID: <CAE=3Ky_fi5ixQp+gYJeV4kYAtr0BmTbRgiaLDUJLDAk8AE-xjA@mail.gmail.com>
To: "Martin J. Dürst" <duerst@it.aoyama.ac.jp>
Cc: Doug Ewell <doug@ewellic.org>, Christian Despres <christian.j.j.despres@gmail.com>, "ietf-languages@ietf.org" <ietf-languages@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000fdf71805f7fb74e2"
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf-languages/XYYGTVESyHFe2kyB5rSnZH86KRw>
Subject: Re: [Ietf-languages] BCP47 violation in the recent extlang ajp change
X-BeenThere: ietf-languages@ietf.org
X-Mailman-Version: 2.1.39
Precedence: list
List-Id: "Review of requests for language tag registration according to BCP 47 \(RFC 4646\)" <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: Tue, 28 Mar 2023 20:11:00 -0000

1. Any larger BCP-47 effort for revision should likely include
incorporating the Unicode Extensions, RFC6067 and RFC6497:

https://cldr.unicode.org/index/bcp47-extension
http://www.unicode.org/reports/tr35/#36-unicode-bcp-47-u-extension

2. The issue with using Glottolog codes is specifically that ISO 639-3 is
scoped at the language level, while the informatic model of the Glottolog
is specifically scoped to the document level, rather than the language
level. That is, Glottolog codes can span the classes of macro-language,
idiolect, dialect, or hypothetical reconstructed language.  The two scopes
are inconsistent with regard to purpose. If the purpose of the positions of
the constructed BCP-47 tags is to stay consistent, I don't see how
Glottolog codes become a possibility except after -x- or some other
yet-to-be defined identifier.

Kind Regards,
Hugh

On Mon, Mar 27, 2023 at 12:43 AM Martin J. Dürst <duerst@it.aoyama.ac.jp>
wrote:

> Hello Doug, others,
>
> Greetings from IETF 116 in Yokohama!
>
> On 2023-03-27 04:16, Doug Ewell wrote:
>
> > In a perfect world, it would be best to be able to keep RFC 5646 and
> publish a short addendum clarifying how to resolve the conflict between
> sections 2.2.2 and 3.1.7.
>
> Not that IETF is perfect, but that's actually possible, and has been
> done many times. A good example would be
> https://www.rfc-editor.org/rfc/rfc8174.html.
>
> Regards,   Martin.
>
> _______________________________________________
> Ietf-languages mailing list
> Ietf-languages@ietf.org
> https://www.ietf.org/mailman/listinfo/ietf-languages
>

v2.23.0 | Report a Bug | By Email