Missing subtags 003 and 172

[Michael Everson]

Mark said:

> Based on the discussion on this list, I put together the form for 003 and sent out.


Mark, please address Doug's comments (below) specifically.

Doug, if your wrath is assuaged, tell us that you agree that the "arguability" of 003 is sufficient to allow this to be processed. You are the one that said adding 003 or 172 is "illegal". 

If **EVERYONE** does not agree on this, then I will reject the proposal, and ask you to initiate an RFC amendment to handle 003 and 172 (Plan B).

Personally, I do not have an opinion. Unanimity, and unanimity ONLY, will get me to approve this proposal. (Then the whole group can be blamed.)

If **ANYONE** has a fundamental objection (the kind of objection which will prevent a YES under **any** circumstances) on the basis of the RFC not permitting this registration, say so now, and Plan B will be the only recourse for solving this.

End of line.
M

On 30 Jul 2010, at 19:25, Doug Ewell wrote:

> 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:
> 
>    001 World
>       019 Americas
>       021 Northern America   <-------------------+
>          419 Latin America and the Caribbean     |
>             005 South
> 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
>>    territory.
> 
> 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
>>    question.
> 
> 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.
> 
> Must not.
> 
> 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 
> 
> 
> _______________________________________________
> Ietf-languages mailing list
> Ietf-languages at alvestrand.no
> http://www.alvestrand.no/mailman/listinfo/ietf-languages

Michael Everson * http://www.evertype.com/