From: Philippe Verdy (verdy_p@wanadoo.fr)
Date: Tue Sep 12 2006 - 10:20:11 CDT
From: "Doug Ewell" <dewell@adelphia.net>
> Technically this is a moot point for users, because they will be using
> subtags from the IANA Language Subtag Registry, not code elements from
> ISO standards. The subtags are based on the ISO standards. It is the
> responsibility of the Language Subtag Reviewer and the
> ietf-languages@iana.org list to make sure any possible conflicts in the
> standards don't find their way into the Registry.
That's a good argumentation that is not clear in RFC 4645 (although this RFC just describes the content of the initial registry), but more importantly in RFC 4646 (given that it gives explicit references to ISO 639 as the source, without making it clear that this is the IANA registry that will prevail in all cases).
So there are probably too strong rules in RFC 4646, and RFC 639 should only be considered as an informative, but not mandatory, source (except for RFC 4645 for the initial content of the IANA registry).
What you seem to say is that the ISO 639 maintenance agency should request additions according to the ISO 4646 rules, and that IANA will update its registry only if it does not violates the ISO 4646 rules. This means that all ISO 639-3 additions as well as any updates to ISO 639-2 or even ISO 639-1 or any part of ISO 3166 or UN M.49 (what about the recent case of Serbia and of Montenegro which are now independant UN members and so will get, or already have, their own numeric code for the next edition of UN statistic reports... even if ISO 3166 is still not updated: who will use YU and CS now?) will not qualify as valid updates in the IANA registry for usage in language tags (if this conflicts with the RFC 4646 stability rules).
So why was it needed to give these sources in the text of RFC 4646? Wouldn't have it been better to keep them outside, or only as informative references, making them normative only with the current version of RFC 4645 that defines the current allocation priority policy?
That's where a part of the confusion comes. ISO 4646 would have been better if it just consisted in describing the IANA registry, and the rules for composing and parsing the language tags. And then adding a reference to RFC 4645 or its successor regarding the current rules allowing inclusions in the IANA registry, rules that will need to be updated later when ISO 639-3 will be released (RFC 4648? if that number is already reserved for such expected update).
This archive was generated by hypermail 2.1.5 : Tue Sep 12 2006 - 10:26:01 CDT