Suggestion: registration of variant subtags for Aluku, Ndyuka, andPamaka (Suriname/French Guiana English-based Creoles)

[Lang Gérard]

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.
Cordialement.
Gérard LANG

________________________________

	De : ietf-languages-bounces at alvestrand.no [mailto:ietf-languages-bounces at alvestrand.no] De la part de CE Whitehead
	Envoyé : mercredi 28 janvier 2009 02:56
	À : ietf-languages at iana.org
	Objet : Suggestion: registration of variant subtags for Aluku, Ndyuka, andPamaka (Suriname/French Guiana English-based Creoles)
	
	
	Hi.
	 
	Doug, Peter, thanks for your corrections.  (My last post was sort of hasty, maybe.) 
	 
	(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??)
	 
	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 http://www.alvestrand.no/pipermail/ietf-languages/2008-March/007672.html but of course, there will -- hopefully-- not be that long a wait for RFC 4646 & it makes sense to wait!)
	 
	Thanks!
	
	--C. E. Whitehead
	cewcathar at hotmail.com 
	 
	Lang Gérard gerard.lang at insee.fr <mailto:ietf-languages at alvestrand.no?Subject=Suggestion: registration of variant subtags for Aluku, Ndyuka,and Pamaka&In-Reply-To=F194087747F64973B778ABDA6D2A0D58 at DGBP7M81> 
	Mon Jan 26 15:49:10 CET 2009 
	
	
	
	
	> 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 
	> 
	Doug Ewell doug at ewellic.org 
	Mon Jan 26 01:12:13 CET 2009 
	 
	> CE Whitehead had written:
	>> As far as I understand, it is possible to change the ISO639-3 codes 
	>> and language names (Joan Span's posting has just reminded me of this), 
	>> but you are right; I do not think a change to the code itself would be 
	>> worth pursuing; if you wished to add additional names however, that 
	>> would be fine:
	> Peter Constable <petercon at microsoft dot com> replied:
	>> It is *not* possible to change the ID of an already-encoded category, 
	>> so requesting such a change is definitely not worth pursuing. Changing 
	>> the name without changing the semantic is possible, however, and 
	>> changes to a semantic are possible with restrictions so as to avoid 
	>> causing existing usage to become invalid.
	> I'm only guessing, 
	> . . . 
	> I think maybe it needs to be stated again that neither this list nor 
	> LTRU is the place to request changes to ISO 639-3, or even to offer 
	> advice about what changes can be made to 639-3.  The RA has a very open 
	> and accessible change-request mechanism, at least when compared to other 
	> ISO standards, and we ought not to try to act as a surrogate for that.
	> CE continued (I missed this earlier):
	>> And we can still approve the variant subtags (once RFC 4646 is 
	>> published?  Is that the consensus?)
	> RFC 4646bis, not 4646.
	> I don't understand why this would be a question of "consensus."  Once 
	> the language subtags are in the Registry -- call it Date D -- we can 
	> review any proposals related to those subtags, such as M. Vaillant's 
	> variants, and the Reviewer can act upon them.  We just can't take any 
	> action on these proposals until Date D.
	
	
	
	 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.alvestrand.no/pipermail/ietf-languages/attachments/20090128/57b7e3d7/attachment-0001.htm