Re: [Ietf-languages] Fwd: Recommendation not to register variant subtags of the form 0nnn

"Phillips, Addison" <addison@lab126.com> Thu, 30 July 2020 19:54 UTC

Return-Path: <prvs=473f0a172=addison@lab126.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 502043A0C46 for <ietf-languages@ietfa.amsl.com>; Thu, 30 Jul 2020 12:54:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.118
X-Spam-Level:
X-Spam-Status: No, score=-1.118 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_NEUTRAL=0.779, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
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 hvvIH671YL4N for <ietf-languages@ietfa.amsl.com>; Thu, 30 Jul 2020 12:54:17 -0700 (PDT)
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 CCFFE3A0C38 for <ietf-languages@ietf.org>; Thu, 30 Jul 2020 12:54:16 -0700 (PDT)
Received: by mork.alvestrand.no (Postfix) id DAEBB7C5987; Thu, 30 Jul 2020 21:54:14 +0200 (CEST)
Delivered-To: ietf-languages@alvestrand.no
X-Comment: SPF skipped for whitelisted relay - client-ip=192.0.46.71; helo=pechora5.dc.icann.org; envelope-from=prvs=473f0a172=addison@lab126.com; receiver=ietf-languages@alvestrand.no
Received: from pechora5.dc.icann.org (pechora5.icann.org [192.0.46.71]) by mork.alvestrand.no (Postfix) with ESMTPS id 8FE077C5218 for <ietf-languages@alvestrand.no>; Thu, 30 Jul 2020 21:54:14 +0200 (CEST)
Received: from smtp-fw-33001.amazon.com (smtp-fw-33001.amazon.com [207.171.190.10]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by pechora5.dc.icann.org (Postfix) with ESMTPS id A04DC700315C for <ietf-languages@iana.org>; Thu, 30 Jul 2020 19:54:12 +0000 (UTC)
IronPort-SDR: xv4Lw6xBNMknnKXTyHRw9+jLxOJqKBv+DFWNGvwAT0C2I60j/+meBDLkaYwqmmesE4RKuxNNIX OVi6+8YjcCVg==
X-IronPort-AV: E=Sophos; i="5.75,415,1589241600"; d="scan'208,217"; a="63121258"
Thread-Topic: [Ietf-languages] Fwd: Recommendation not to register variant subtags of the form 0nnn
Received: from sea32-co-svc-lb4-vlan3.sea.corp.amazon.com (HELO email-inbound-relay-1d-9ec21598.us-east-1.amazon.com) ([10.47.23.38]) by smtp-border-fw-out-33001.sea14.amazon.com with ESMTP; 30 Jul 2020 19:53:31 +0000
Received: from EX13MTAUWB001.ant.amazon.com (iad55-ws-svc-p15-lb9-vlan2.iad.amazon.com [10.40.159.162]) by email-inbound-relay-1d-9ec21598.us-east-1.amazon.com (Postfix) with ESMTPS id 03C12A248A; Thu, 30 Jul 2020 19:53:29 +0000 (UTC)
Received: from EX13D08UWB003.ant.amazon.com (10.43.161.186) by EX13MTAUWB001.ant.amazon.com (10.43.161.249) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Thu, 30 Jul 2020 19:53:29 +0000
Received: from EX13D08UWB002.ant.amazon.com (10.43.161.168) by EX13D08UWB003.ant.amazon.com (10.43.161.186) with Microsoft SMTP Server (TLS) id 15.0.1497.2; Thu, 30 Jul 2020 19:53:28 +0000
Received: from EX13D08UWB002.ant.amazon.com ([10.43.161.168]) by EX13D08UWB002.ant.amazon.com ([10.43.161.168]) with mapi id 15.00.1497.006; Thu, 30 Jul 2020 19:53:28 +0000
From: "Phillips, Addison" <addison@lab126.com>
To: John Cowan <cowan@ccil.org>, Peter Constable <pgcon6@msn.com>
CC: IETF Languages Discussion <ietf-languages@iana.org>, Doug Ewell <doug@ewellic.org>
Thread-Index: AQHWZcUdK4RROo1FC0+hZs7v9Jq7bakfCg4AgAFOnICAACa2AIAABngw
Date: Thu, 30 Jul 2020 19:53:28 +0000
Message-ID: <296dba79334f4606a20cb2be7183c7f0@EX13D08UWB002.ant.amazon.com>
References: <a66144d8bae24114a1b1e64144ca1088@EX13D08UWB002.ant.amazon.com> <CAD2gp_Thc3pNicD-2+bMmaaBZPaLiyQzvVrPK+C+Y9NNCiBwCA@mail.gmail.com> <CAD2gp_QeVRfvKVUr9a5avwzZS=EV0rri9Yvx0wcQzt1TaV7QFQ@mail.gmail.com> <000901d665ea$cd03a890$670af9b0$@ewellic.org> <MWHPR1301MB2112B310AF8F32515110BF2786710@MWHPR1301MB2112.namprd13.prod.outlook.com> <CAD2gp_R7KAOof+2caJiZGXdFNsGSp7U_ut56BLQVvVwADteH=Q@mail.gmail.com>
In-Reply-To: <CAD2gp_R7KAOof+2caJiZGXdFNsGSp7U_ut56BLQVvVwADteH=Q@mail.gmail.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: [10.43.162.248]
Content-Type: multipart/alternative; boundary="_000_296dba79334f4606a20cb2be7183c7f0EX13D08UWB002antamazonc_"
MIME-Version: 1.0
X-Greylist: Sender passed SPF test, not delayed by milter-greylist-4.6.2 (pechora5.dc.icann.org [0.0.0.0]); Thu, 30 Jul 2020 19:54:12 +0000 (UTC)
Archived-At: <https://mailarchive.ietf.org/arch/msg/ietf-languages/wivXMJUl_x-P1-y3O1Y0W3opq6E>
Subject: Re: [Ietf-languages] Fwd: Recommendation not to register variant subtags of the form 0nnn
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: Thu, 30 Jul 2020 19:54:20 -0000

Hi John,

I suspect the problem is:

We don’t intend to open up BCP47 to add this to the official rules, thus this is merely a guideline or best practice that is only enforced by the judgement of the registrar as advised by this list. If we intend for there to be guidelines/best practices/learnings/policies that tag requesters should adhere to or at least consider (as learnings from having operated a subtag registry for some years now) and if these were to be written down, that might make a suitable addition for this forum to debate. It seems reasonable to me as an observation. Having a sort of “history of past debates that will inform your tag choices” in a wiki or other document might even be advisable—I am not volunteering to write it though.

We could just all say “ sure, John” and then go back to our lives, safe in the knowledge that if such a variant were proposed, the proposal being legal, the net effect would be the same—someone would have to remember and apply this as guidance and then we’d have to debate it if the requester didn’t like the proposal, with the ultimate arbiter being Michael (and/or the appeals process).

Is what you’re looking for a milestone in the archives where someone (probably Michael) says: “all things being equal, this will be my policy going forwards” so that there is something to point to later? This won’t fix the above case, but at least this group has debated it as a quondam policy upon later consumption.

Or, as Doug said:

    > I appreciate the nemawashi and suggest that we try to not enact any firm decisions, but keep this idea in mind whenever an all-numeric variant subtag is being floated.

Addison

From: Ietf-languages [mailto:ietf-languages-bounces@ietf.org] On Behalf Of John Cowan
Sent: Thursday, July 30, 2020 12:13 PM
To: Peter Constable <pgcon6@msn.com>
Cc: IETF Languages Discussion <ietf-languages@iana.org>; Doug Ewell <doug@ewellic.org>
Subject: RE: [EXTERNAL] [Ietf-languages] Fwd: Recommendation not to register variant subtags of the form 0nnn


CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe.


What I am suggesting is simplicity itself:

Even though 4-digit variant subtags are legal, do not register any that begin with 0.

Instead ask the requester to use some other subtag.  Exactly what other subtag can be settled case-by-case when the time comes.



On Thu, Jul 30, 2020 at 12:54 PM Peter Constable <pgcon6@msn.com<mailto:pgcon6@msn.com>> wrote:
This:
> Our existing UN M49-based region subtags that begin with “0” are already subject to this.

If it hasn’t been a problem over the past 10+ years for existing and in-use numeric region subtags, it’s not clear why we would need to change anything for hypothetical variant subtags.


Peter

From: Ietf-languages <ietf-languages-bounces@ietf.org<mailto:ietf-languages-bounces@ietf.org>> On Behalf Of Doug Ewell
Sent: Wednesday, July 29, 2020 1:57 PM
To: 'John Cowan' <cowan@ccil.org<mailto:cowan@ccil.org>>; 'IETF Languages Discussion' <ietf-languages@iana.org<mailto:ietf-languages@iana.org>>
Subject: Re: [Ietf-languages] Fwd: Recommendation not to register variant subtags of the form 0nnn

I understand the intent, although there are plenty of opportunities already for confusion.

I have a colleague who often refers to the bogus tag ”en-EN” by analogy with “fr-FR” and “es-ES” and “it-IT”. (The organization doesn’t fully get that region subtags aren’t always necessary or desirable.)

Our existing UN M49-based region subtags that begin with “0” are already subject to this. One of them, “en-029”, even has some currency. I don’t know if there has been any confusion around the leading zero. I know from a quick web scan that there is plenty of confusion from people who think a region subtag can only be an ISO 3166-1 code element, or who are still stuck in RFC 1766 and think a language subtag can only be two letters.

I appreciate the nemawashi and suggest that we try to not enact any firm decisions, but keep this idea in mind whenever an all-numeric variant subtag is being floated.

--
Doug Ewell | Thornton, CO, US | ewellic.org<http://ewellic.org>