Missing subtags 003 and 172
doug at ewellic.org
Fri Jul 30 20:25:53 CEST 2010
Michael Everson <everson at evertype dot com> wrote:
> I would prefer to approve 003 and 172, however, than to have to bear with weeks of arguing about whether they can be proposed or not.
We have NO provision in BCP 47 for this. We can (and do) register
variant subtags and 5-to-8-letter language subtags. We can (and do)
add, change, or deprecate subtags based on external standards if the
corresponding code element in the standard is added, changed, or
deleted. What we CANNOT do is change our procedural rules about which
code elements in external standards are used to create subtags and which
are not, and start registering region subtags based on new opinions or
needs of different projects that weren't reviewed by the LTRU Working
Group and IETF Last Call.
I do not support registering anything, ever, if there is doubt as to
whether it is legal to do so, and especially not as a mechanism to avoid
determining whether it is legal.
As for utility, I am starting to see the point about 003, although I
still contend that the decision by the UNSD to place this in a footnote
is not accidental, as it doesn't fit the hierarchy:
021 Northern America <-------------------+
419 Latin America and the Caribbean |
America +- 003 North America
013 Central America <--------------+
029 Caribbean <--------------------+
172 is unquestionably out of scope for language tagging, every bit as
much as 199 ("Least developed countries").
Quoting from the RFC via Mark:
> A. UN numeric codes assigned to 'macro-geographical
> (continental)' or sub-regions MUST be registered in the
> registry. These codes are not associated with an assigned
> ISO 3166-1 alpha-2 code and represent supra-national areas,
> usually covering more than one nation, state, province, or
003 is listed only in the footnote, not in the chart proper, alongside
other footnotes dealing with concepts like "sub-Saharan Africa" and
"developed" and "developing" countries. Unlike the others, an
associated code element is given. Again, this one is arguable.
> B. UN numeric codes for 'economic groupings' or 'other
> groupings' MUST NOT be registered in the IANA registry and
> MUST NOT be used to form language tags.
Thereby excluding 172.
> C. When ISO 3166-1 reassigns a code formerly used for one
> country or area to another country or area and that code
> already is present in the registry, the UN numeric code for
> that country or area MUST be registered in the registry as
> described in Section 3.4 and MUST be used to form language
> tags that represent the country or region for which it is
> defined (rather than the recycled ISO 3166-1 code).
Not relevant; pertains to recycled ISO 3166 code elements.
> D. UN numeric codes for countries or areas for which there is an
> associated ISO 3166-1 alpha-2 code in the registry MUST NOT
> be entered into the registry and MUST NOT be used to form
> language tags. Note that the ISO 3166-based subtag in the
> registry MUST actually be associated with the UN M.49 code in
Not relevent; pertains to duplicate alpha and numeric coding.
> E. For historical reasons, the UN numeric code 830 (Channel
> Islands), which was not registered at the time this document
> was adopted and had, at that time, no corresponding ISO
> 3166-1 code, MAY be entered into the IANA registry via the
> process described in Section 3.5, provided no ISO 3166-1 code
> with that exact meaning has been previously registered.
Not relevant; specific exception for 830.
> 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.
Back to Michael:
> Or I would prefer to have you post an RFC for this if that is the way it must be done.
I wonder how quickly this could be done, if a decent use case is
produced for 003 and the Reviewer and group decide it should be added.
I wonder if the RFC could be an individual submission and not go through
the whole WG process.
Doug Ewell | Thornton, Colorado, USA | http://www.ewellic.org
RFC 5645, 4645, UTN #14 | ietf-languages @ is dot gd slash 2kf0s
More information about the Ietf-languages