<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=Content-Type content="text/html; charset=iso-8859-1">
<STYLE>.hmmessage P {
PADDING-RIGHT: 0px; PADDING-LEFT: 0px; PADDING-BOTTOM: 0px; MARGIN: 0px; PADDING-TOP: 0px
}
BODY.hmmessage {
FONT-SIZE: 10pt; FONT-FAMILY: Verdana
}
</STYLE>
<META content="MSHTML 6.00.2900.3492" name=GENERATOR></HEAD>
<BODY class=hmmessage>
<DIV dir=ltr align=left><SPAN class=842530607-28012009><FONT face=Arial
color=#0000ff>The case with NM is that ISO 3166-1 has an entry (AN, ANT, 530)
for NETHERLAND ANTILLES. But this dutch territory, that groups 4 1/2 islands
(Bonaire, Curacao, Saba, Saint Eustatius and the southern part of Saint Martin
[whose northern part is french]) in Antiles, should soon split. So that 3
islands (Bonaire, Saba and Saint Eustatius) should directly return inside
NETHERLANDS (NL, NLD, 528) and the two others part receive an autonomy status,
like ARUBA (AW, ABW, 533); so that we certainly will have 2 nerw entries in ISO
3166-1 for CURACAO and the dutch part of SAINT MARTIN and must choose alpha-2
code elements to represent the country names of both territories. MN is not
free, but NM is free. Some could say that "N" has no occurence in the english
name "SAINT MARTIN (DUTCH PART), but this is not the case for the french name
"SAINT-MARTIN (PARTIE NEERLANDAISE)" that provides an equivalent basis for
representation and coding of the country name.</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=842530607-28012009><FONT face=Arial
color=#0000ff>Cordialement.</FONT></SPAN></DIV>
<DIV dir=ltr align=left><SPAN class=842530607-28012009><FONT face=Arial
color=#0000ff>Gérard LANG</FONT></SPAN></DIV>
<BLOCKQUOTE dir=ltr style="MARGIN-RIGHT: 0px">
<DIV class=OutlookMessageHeader lang=fr dir=ltr align=left>
<HR tabIndex=-1>
<FONT face=Tahoma><B>De :</B> ietf-languages-bounces@alvestrand.no
[mailto:ietf-languages-bounces@alvestrand.no] <B>De la part de</B> CE
Whitehead<BR><B>Envoyé :</B> mercredi 28 janvier 2009
02:56<BR><B>À :</B> ietf-languages@iana.org<BR><B>Objet :</B>
Suggestion: registration of variant subtags for Aluku, Ndyuka, andPamaka
(Suriname/French Guiana English-based Creoles)<BR></FONT><BR></DIV>
<DIV></DIV>Hi.<BR> <BR>Doug, Peter, thanks for your corrections.
(My last post was sort of hasty, maybe.) <BR> <BR>(I assume M.
Lang wants NM because MN is taken but I think we only
register region codes when a UN M.49 code becomes available with no
ISO 3166 code??? or else when a 3166-1 code is created with no corresponding
UN M.49 code??? Both seem like odd situations??? Someone please
clarify this discussion for me; I thought we only registered variants,
but it seems that the language subtag reviewer can also, in some unusual
circumstances, register region codes??)<BR> <BR>Back to the
variants: I'm fine with waiting till till RFC 4646 is
published before considering M. Vaillant's variants; (Sorry;
I thought that discussion was o.k. since we had discussed "erzgeb"
while waiting for a successor of RFC 4646 ; see <A
href="http://www.alvestrand.no/pipermail/ietf-languages/2008-March/007672.html">http://www.alvestrand.no/pipermail/ietf-languages/2008-March/007672.html</A> but
of course, there will -- hopefully-- not be that long a wait for RFC 4646
& it makes sense to wait!)<BR> <BR>Thanks!<BR><BR>--C. E.
Whitehead<BR><A href="mailto:cewcathar@hotmail.com">cewcathar@hotmail.com</A>
<BR> <BR>Lang Gérard <A
title="Suggestion: registration of variant subtags for Aluku, Ndyuka,	and Pamaka"
href="mailto:ietf-languages@alvestrand.no?Subject=Suggestion: registration of variant subtags for Aluku, Ndyuka,and Pamaka&In-Reply-To=F194087747F64973B778ABDA6D2A0D58@DGBP7M81"><FONT
color=#000000>gerard.lang at insee.fr </FONT></A><BR>Mon Jan 26 15:49:10 CET
2009 <BR><BR><BR><BR><PRE>> Dear Doug,
> 2-The alpha-2 code element "MF" is associated with the country name "SAINT-MARTIN (FRENCH PART)", so that M is for Saint-Martin, and F for French part.
> And if SINT-MAARTEN, that will soon no more be part of Netherlands Antilles, becomes a new entry inside ISO 3166-1, a code element like NM (N for Netherlands and M for Maarten) would be very good to see the separation of the territory of this islands betweem two sovereignties !
> Bien cordialement.
> Gérard LANG <BR>> <BR>Doug Ewell doug at ewellic.org <BR></PRE><PRE>Mon Jan 26 01:12:13 CET 2009 <BR> <BR>> CE Whitehead had written:<BR>>> As far as I understand, it is possible to change the ISO639-3 codes <BR>>> and language names (Joan Span's posting has just reminded me of this), <BR>>> but you are right; I do not think a change to the code itself would be <BR>>> worth pursuing; if you wished to add additional names however, that <BR>>> would be fine:<BR>> Peter Constable <petercon at microsoft dot com> replied:<BR>>> It is *not* possible to change the ID of an already-encoded category, <BR>>> so requesting such a change is definitely not worth pursuing. Changing <BR>>> the name without changing the semantic is possible, however, and <BR>>> changes to a semantic are possible with restrictions so as to avoid <BR>>> causing existing usage to become invalid.<BR>> I'm only guessing, <BR>> . . . <BR>> I think maybe it needs to be stated again that neither this list nor <BR>> LTRU is the place to request changes to ISO 639-3, or even to offer <BR>> advice about what changes can be made to 639-3. The RA has a very open <BR>> and accessible change-request mechanism, at least when compared to other <BR>> ISO standards, and we ought not to try to act as a surrogate for that.<BR>> CE continued (I missed this earlier):<BR>>> And we can still approve the variant subtags (once RFC 4646 is <BR>>> published? Is that the consensus?)<BR>> RFC 4646bis, not 4646.<BR>> I don't understand why this would be a question of "consensus." Once <BR>> the language subtags are in the Registry -- call it Date D -- we can <BR>> review any proposals related to those subtags, such as M. Vaillant's <BR>> variants, and the Reviewer can act upon them. We just can't take any <BR>> action on these proposals until Date D.<BR><BR><BR><BR> <BR></PRE></BLOCKQUOTE></BODY></HTML>