Subject: Re: [Ietf-languages] Missing M.49 code

From: "Doug Ewell" <[email-masked]>
Date: Tue, 13 Feb 2018 11:34:23 -0700

Mark Davis wrote:

> There is one code missing from M.49, the code "680" for "Sark". 

This is excluded by RFC 5646, Section 3.4, item 16:

"UN M.49 has codes for both "countries and areas" (such as '276' for
Germany) and "geographical regions and sub-regions" (such as '150' for
Europe). UN M.49 country or area codes for which there is no
corresponding ISO 3166-1 code MUST NOT be registered, except as a
surrogate for an ISO 3166-1 code that is blocked from registration by an
existing subtag."

Section 2.2.4, item 4 says the same.
 
--
Doug Ewell | Thornton, CO, US | ewellic.org

---

From: Mark Davis ☕️ <[email-masked]>
Date: Mon, 19 Feb 2018 16:07:19 +0100

Thanks, Doug. I missed that, sorry for the confusion.

Makr

Mark

---

From: John Cowan <[email-masked]>
Date: Mon, 19 Feb 2018 18:19:05 -0500

The Maintenance Agency is ISO itself.  I contacted them about assigning an
alphabetic code to Sark, but they told me to contact ANSI.  I have
forwarded my request there.

---

From: "Doug Ewell" <[email-masked]>
Date: Mon, 19 Feb 2018 23:45:52 -0700

John Cowan wrote:

> The Maintenance Agency is ISO itself.  I contacted them about
> assigning an alphabetic code to Sark, but they told me to contact
> ANSI.  I have forwarded my request there.

Is this desired because

(a) there is actual linguistic content in Sercquiais (or the "Sark 
variety" of some other language) that needs to be tagged,

(b) because there is a desire to create CLDR locale data for Sark, or

(c) simply because CLDR somehow expects every UN M.49 code element to 
have a corresponding ISO 3166-1 alpha-2 code element?

The latter, at least, would seem to be an artificial assumption.

---

From: Mark Davis ☕️ <[email-masked]>
Date: Tue, 20 Feb 2018 12:16:28 +0100

(a) Not a relevant objection. There may well be a need; BCP47 is structured
so that we don't have to care whether there is a "need" for ja-AQ, etc.

(b), (c) General-purpose software has come to depend on the LSTR for stable
codes. Having a misalignment does nobody any good.

And thanks to John for contacting the right people.

Mark

On Tue, Feb 20, 2018 at 7:45 AM, Doug Ewell <[email-masked]> wrote:

> (c) simply because CLDR somehow expects every UN M.49 code element to have
> a corresponding ISO 3166-1 alpha-2 code element?
>