Subject: [Ltru] Ticket #36: AD Issue #3: rules for UN M.49 codes

From: "Phillips, Addison" <[email-masked]>
Date: Tue, 28 Apr 2009 21:38:10 -0700

The AD suggested:

--
Issue #3 from AD review - for details see
http://www.ietf.org/mail-archive/web/ltru/current/msg12399.html

3). Section 2.2.4 says:

    F. All other UN numeric codes for countries or areas that do not
    have an associated ISO 3166-1 alpha-2 code MUST NOT be
    entered into the registry and MUST NOT be used to form
    language tags. For more information about these codes, see
    Section 3.4.

And Section 3.4 says:

    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 SHOULD NOT be

Unless I am confused, I think this SHOULD NOT contradicts MUST NOT in
section 2.2.4.
I think you need to change one of 2 sections.

    registered, except as a surrogate for an ISO 3166-1 code that is
    blocked from registration by an existing subtag. If such a code
    becomes necessary, then the registration authority for ISO
    3166-1 SHOULD first be petitioned to assign a code to the
    region. If the petition for a code assignment by ISO 3166-1 is
    refused or not acted on in a timely manner, the registration
    process described in Section 3.5 MAY then be used to register
    the corresponding UN M.49 code. This way, UN M.49 codes remain
    available as the value of last resort in cases where ISO 3166-1
    reassigns a deprecated value in the registry.
--

I believe the AD has a point here. Note that Rule F in 2.2.4 is not complete unto itself. The rules in that section for UN M.49 codes are (basically):

- continents and subregions: registered
- economic and 'other' groupings: excluded
- codes associated with codes recycled by ISO 3166: registered
- codes otherwise associated with ISO 3166 codes: excluded
- code 830: permitted to be (but not currently) registered
- any other codes: excluded

The rule #16 in section 3.4 is a restatement of one of the above rules (specifically, the fourth one). I recall that we added the text in rule #16 during this document's gestation.

Proposed resolution:

I propose that we change the text in section 2.2.4 to read:

<t>Other UN numeric codes for countries or areas that do not have an associated ISO 3166-1 alpha-2 code MAY be entered into the registry via the process described in <xref target="registrationProc"></xref>, subject to the restrictions in <xref target="ianastability"></xref>, item #16.</t>

Addison Phillips
Globalization Architect -- Lab126

Internationalization is not a feature.
It is an architecture.

---

From: "Randy Presuhn" <[email-masked]>
Date: Thu, 30 Apr 2009 09:52:10 -0700

Hi -

As a technical contributor...

> From: "Phillips, Addison" <[email-masked]>
> To: "LTRU Working Group" <[email-masked]>
> Sent: Tuesday, April 28, 2009 9:38 PM
> Subject: [Ltru] Ticket #36: AD Issue #3: rules for UN M.49 codes
>

> The rule #16 in section 3.4 is a restatement of one of the above rules (specifically, the fourth one). I recall that we added the
text in rule #16 during this document's gestation.
> <t>Other UN numeric codes for countries or areas that do not have an associated ISO 3166-1 alpha-2 code MAY be entered into the
registry via the process described in <xref target="registrationProc"></xref>, subject to the restrictions in <xref
target="ianastability"></xref>, item #16.</t>
...

I disagree with the proposed resolution.  A problem in the proposal
is that the "SHOULD NOT" in 3.4 (16) would remain, and this "SHOULD
NOT" is not what we intended, as I recall.  We intended "MUST NOT ... except".
The difference is important.  A "SHOULD NOT" leaves it open to the
deployer / implementer to come up with excuses for doing something.
We intended that there should only be one possible excuse for doing it.

Sooo....

I think it is sufficient to replace the "SHOULD NOT" in 3.4 (16) with
"MUST NOT".  This would address the AD's concern, and would be
entirely in keeping with the intent of the passage.

Randy

---

From: "Phillips, Addison" <[email-masked]>
Date: Thu, 30 Apr 2009 09:56:35 -0700

Hi,

(individually)

This makes sense to me.

(as editor)

I have reverted the text in 2.2.4 and changed SHOULD NOT to MUST NOT in section 3.4.

Addison

Addison Phillips

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On
> Behalf Of Randy Presuhn
> Sent: Thursday, April 30, 2009 9:52 AM
> To: LTRU Working Group
> Subject: Re: [Ltru] Ticket #36: AD Issue #3: rules for UN M.49
> codes
> 
> Hi -
> 
> > I believe the AD has a point here. Note that Rule F in 2.2.4 is
> not complete unto itself. The rules in that section for UN M.49
> codes are (basically):
> >
> > The rule #16 in section 3.4 is a restatement of one of the above
> rules (specifically, the fourth one). I recall that we added the
> > <t>Other UN numeric codes for countries or areas that do not have
> an associated ISO 3166-1 alpha-2 code MAY be entered into the
> registry via the process described in <xref
> target="registrationProc"></xref>, subject to the restrictions in
> <xref
> _______________________________________________
> Ltru mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/ltru