Saint Helena, Ascension and Tristan da Cunha

Randy Presuhn randy_presuhn at mindspring.com
Mon Mar 1 04:18:44 CET 2010


Hi -

> From: "Doug Ewell" <doug at ewellic.org>
> To: <ietf-languages at iana.org>
> Sent: Sunday, February 28, 2010 6:44 PM
> Subject: Saint Helena, Ascension and Tristan da Cunha 
>
> ISO 3166-1 Newsletter VI-7, dated 2010-02-22 (but not posted until a few 
> days later), announces a name change for code element SH from "Saint 
> Helena" to "Saint Helena, Ascension and Tristan da Cunha."  This doesn't 
> represent as much of a scope increase as it might seem, since the 
> Remarks entry for SH previously stated that the code element "included" 
> Ascension Island and the Tristan da Cunha Archipelago.
> 
> Normally for us, this simple ISO 3166/MA action would trigger a simple 
> change to the Description field for subtag SH.  However, because the 
> LTRU WG decided to add the ISO 3166-1 "exceptionally reserved" code 
> elements to the Registry -- including AC for Ascension Island and TA for 
> Tristan da Cunha -- we have a decision to make.  In addition to making 
> the name change for SH, do we also deprecate AC and TA and give each a 
> Preferred-Value of SH?
> 
> According to RFC 5646, "Usually, the addition of a 'Deprecated' field is 
> due to the action of one of the standards bodies, such as ISO 3166, 
> withdrawing a code."  Obviously the MA would not have "withdrawn" these 
> two code elements, since they were not assigned, only reserved.  It is 
> we (LTRU) who chose to put these reserved code elements on an equal 
> footing with normal assigned code elements.
> 
> My opinion should be clear -- deprecate AC and TA -- but I'll wait to 
> hear from others before posting any forms to the list.
...

I think there's no need to deprecate AC or TA.  What they refer to are
subsets of what is (and was) referred to be SH.  Nothing has changed as
far as AC and TA are concerned.  What SH refers to has not changed.  What
AC would refer to has not changed.  What TA would refer to has not changed.
All that should be done is the simple change to the SH subtag's Description
field.

Those tagging language usage in that part of the globe will, based on their
own needs and the data, need to make the determination whether distinguishing
AC or TA specifically from the larger SH (or something else) happens to be a
worthwhile distinction or not.  I don't see any value in this group attempting
to pre-judge that case.

Randy



More information about the Ietf-languages mailing list