Proposal to reserve ISO 3166-1 code elements

McDonald, Ira imcdonald at sharplabs.com
Fri Apr 14 00:40:21 CEST 2006


+1

I agree with Doug's rationale for protecting these codes
from reassignment.  And I agree with Doug's rationale to
avoid the unpleasant use of UN numeric codes that might
be forced on the Language Subtag Registry by our rules.

Cheers,
- Ira

Ira McDonald (Musician / Software Architect)
Blue Roof Music / High North Inc
PO Box 221  Grand Marais, MI  49839
phone: +1-906-494-2434
email: imcdonald at sharplabs.com

> -----Original Message-----
> From: ietf-languages-bounces at alvestrand.no
> [mailto:ietf-languages-bounces at alvestrand.no]On Behalf Of Mark Davis
> Sent: Wednesday, April 12, 2006 10:42 AM
> To: Doug Ewell
> Cc: ietf-languages at iana.org; Debbie Garside
> Subject: Re: Proposal to reserve ISO 3166-1 code elements
> 
> 
> I absolutely agree that these code elements should be reserved by the 
> ISO 3166 MA and never reused for different entities.
> 
> Mark
> 
> Doug Ewell wrote:
> > This post deals with a proposal to classify 15 unassigned 
> ISO 3166-1 
> > code elements as "reserved."  Please don't dismiss this subject as 
> > "off-topic" for ietf-languages until you have read the entire post.
> >
> > In a message to ietf-languages on April 3, I listed 15 
> formerly used 
> > code elements from ISO 3166-1 that are classified not as 
> > "transitionally reserved" or otherwise "reserved," but as 
> > "unassigned."  These 15 code elements are summarized as follows:
> >
> > DD   German Democratic Republic (withdrawn 1990)
> > YD   Yemen, People's Democratic Republic of (withdrawn 1990)
> > 13 others:  BQ, CT, FQ, HV, JT, MI, NH, NQ, PC, PU, PZ, VD, WK 
> > (withdrawn 1977 through 1986)
> >
> > Note that the code elements DD and YD, having been withdrawn after 
> > 1988 -- "Date A" for purposes of the Language Subtag 
> Registry -- are 
> > included in the Registry as deprecated region subtags.
> >
> > Since then, I have had a chance to read an actual copy of 
> ISO 3166-3, 
> > which shows that the alpha-4 code elements in that standard 
> represent 
> > not only "formerly used names of countries" (Section 1) but also 
> > formerly used code elements.
> >
> > Section 5.2 states that the ISO 3166-3 code list includes "... the 
> > formerly used country names together with their obsolescent alpha-2 
> > code elements, obsolescent alpha-3 code elements, obsolescent 
> > numeric-3 code elements (where relevant), [and] the period (years) 
> > during which these were valid...."
> >
> > This demonstrates that the 15 code elements in the list above, now 
> > present as the first part of ISO 3166-3 code elements, were 
> officially 
> > assigned and valid in ISO 3166 and/or 3166-1 for a clearly defined 
> > period of time.  Based on current practice within ISO 
> 3166/MA -- see 
> > TP, YU, and ZR in recent times -- these 15 code elements should be 
> > classified as "transitionally reserved" to prevent, or at least 
> > discourage, their reassignment to other country names.
> >
> > This issue affects the ietf-languages list because of the 
> presence of 
> > DD and YD.  If the MA were to assign either of these code 
> elements to 
> > a new country name, the code element could not be used in 
> the Language 
> > Subtag Registry because of its existing meaning.  According 
> to Section 
> > 3.4, item 10 of RFC 3066bis, it would be necessary to use 
> the UN M.49 
> > numeric code element as a subtag, something we in LTRU 
> tried hard to 
> > avoid doing.  Item 11 refers to the M.49 codes as "the 
> value of last 
> > resort in cases where ISO 3166 reassigns a deprecated value in the 
> > registry," but clearly it is desirable to avoid this "last resort" 
> > situation.
> >
> > A similar situation could potentially apply to other users of ISO 
> > 3166-1, especially if they also depend on certain withdrawn code 
> > elements to preserve stability, as we do.
> >
> > Debbie Garside and I have talked about this issue and agree 
> that the 
> > MA should be asked to reserve these code elements, 
> especially DD and 
> > YD, but we would like to get input (and hopefully support) from 
> > ietf-languages first.  Please send any comments you may have to the 
> > list, or to Debbie or me, in the next few days before we 
> submit this 
> > to the MA.  If you reply to the list, please try to keep the scope 
> > focused on the impact on the Language Subtag Registry.
> >
> > -- 
> > Doug Ewell
> > Fullerton, California, USA
> > http://users.adelphia.net/~dewell/
> >
> > -- 
> > Debbie Garside
> > Managing Director
> >
> > ICT Marketing Limited
> > Corner House
> > Barn Street
> > Haverfordwest
> > Pembrokeshire SA61 1BW
> > Wales UK
> >
> > Tel: 0044 (0)1437 766441
> > Web: www.ictmarketing.co.uk
> >
> >
> > _______________________________________________
> > Ietf-languages mailing list
> > Ietf-languages at alvestrand.no
> > http://www.alvestrand.no/mailman/listinfo/ietf-languages
> >
> >
> _______________________________________________
> Ietf-languages mailing list
> Ietf-languages at alvestrand.no
> http://www.alvestrand.no/mailman/listinfo/ietf-languages
> 
> -- 
> No virus found in this incoming message.
> Checked by AVG Free Edition.
> Version: 7.1.385 / Virus Database: 268.4.1/311 - Release 
> Date: 4/13/2006
>  
> 

-- 
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.1.385 / Virus Database: 268.4.1/311 - Release Date: 4/13/2006
 


More information about the Ietf-languages mailing list