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